先来看一个FS的coredump的堆栈信息。 你看到这个慌不慌？
#0 0x00007f62d15af1f7 in raise () from /usr/lib64/libc.so.6
#1 0x00007f62d15b08e8 in abort () from /usr/lib64/libc.so.6
#2 0x00007f62d15eef47 in __libc_message () from /usr/lib64/libc.so.6
#3 0x00007f62d1689d87 in __fortify_fail () from /usr/lib64/libc.so.6
#4 0x00007f62d1687f40 in __chk_fail () from /usr/lib64/libc.so.6
#5 0x00007f62d1689cf7 in __fdelt_warn () from /usr/lib64/libc.so.6
#6 0x00007f62b7bd0095 in ldns_sock_wait () from /usr/lib64/libldns.so.1
#7 0x00007f62b7bd057f in ldns_udp_send () from /usr/lib64/libldns.so.1
#8 0x00007f62b7bd0d1a in ldns_send_buffer () from /usr/lib64/libldns.so.1
#9 0x00007f62b7bd1029 in ldns_send () from /usr/lib64/libldns.so.1
#10 0x00007f62b7bd5e9d in ldns_resolver_send_pkt () from /usr/lib64/libldns.so.1
#11 0x00007f62b7bd62c2 in ldns_resolver_send () from /usr/lib64/libldns.so.1
#12 0x00007f62b7bd6400 in ldns_resolver_query () from /usr/lib64/libldns.so.1
#13 0x00007f62b7dfd3d0 in ldns_lookup () from /usr/lib64/freeswitch/mod/mod_enum.so
#14 0x00007f62b7dfd61a in enum_lookup () from /usr/lib64/freeswitch/mod/mod_enum.so
#15 0x00007f62b7dfd817 in enum_dialplan_hunt () from /usr/lib64/freeswitch/mod/mod_enum.so
#16 0x00007f62d3d57dbf in switch_core_session_run () from /usr/lib64/libfreeswitch.so.1
#17 0x00007f62d3d5033e in switch_core_session_thread () from /usr/lib64/libfreeswitch.so.1
#18 0x00007f62d3d4bd83 in switch_core_session_thread_pool_worker () from /usr/lib64/libfreeswitch.so.1
#19 0x00007f62d4012900 in dummy_worker () from /usr/lib64/libfreeswitch.so.1
#20 0x00007f62d2017e25 in start_thread () from /usr/lib64/libpthread.so.0
#21 0x00007f62d167234d in clone () from /usr/lib64/libc.so.6
反正一开始我慌的一批。FreeSwitch的coredump，我又要开始扒代码了。
镇定下来一看，好像还不是FS的锅。问题出在ldns三方库上。根据coredump的时间，在FS日志中找一找看看是否有线索。
coredump时日志位置
再根据这里的提示找一下源码
mod_emun:495
看到这里难道和resolv.conf有关？ 这个和DNS解析有关，检查了这个文件，也没有太大问题。应该不是这个原因。
在看一下日志，这里的17940046812410296实际上是拨号计划里的DestinationNumber。为什么会有这么奇怪的DestinationNumber？
我检查了FS上的拨号计划，里面也没有配置过如此怪异的DestinationNumber。难道是网络上的攻击？
再次查看日志，发先这种奇怪的DestinationNumber出现次数比较多。
还是问一下谷歌吧。似乎找到了问题原因。请看下面的参考。
概括一下就是ldns库中的 ldns_sock_wait使用了select等待socket。但是select使用的socket数组长度是1024。 如果超过了这个长度，这里就crash了。
明白了这个原因，重新再来日志中统计一下奇怪的DestinationNumber
[root@fs freeswitch]# grep "ENUM Lookup on" freeswitch.log | wc -l
1083
好吧。黑客你赢了。
那么如何解决呢？
首先，可以选择参考中的方案，升级ldns库。但我觉得治标不治本。根本原因还是因为受到了网络攻击。
我把防火墙打开后，好了。（原谅我之前一直没有开防火墙）
