GDB定位诡异的FreeSWITCH编译问题

【问题现象】

在freeswitch控制台中，使用show channels命令检查当前会话时，发现有部分垃圾数据(会话已经结束，但系统中还保留着该会话信息)

freeswitch@internal> show channels
uuid,direction,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,dialplan,context,read_codec,read_rate,read_bit_rate,write_codec,write_rate,write_bit_rate,secure,hostname,presence_id,presence_data,callstate,callee_name,callee_num,callee_direction,call_uuid,sent_callee_name,sent_callee_num,initial_cid_name,initial_cid_num,initial_ip_addr,initial_dest,initial_dialplan,initial_context
46a38a98-0abe-11e7-9a47-bbab893a85bc,inbound,2017-03-1711:03:20,1489719800,sofia/internal/138xxxxxxxx@172.xx.xx.xx,CS_EXECUTE,138xxxxxxxx,138xxxxxxxx,172.xx.xx.xx,188xxxxxxxx,bridge,user/188xxxxxxxx@172.xx.xx.xx,XML,public,opus,16000,0,opus,16000,0,,vhost212.test.quality,138xxxxxxxx@172.xx.xx.xx,,ACTIVE,OutboundCall,188xxxxxxxx,SEND,46a38a98-0abe-11e7-9a47-bbab893a85bc,OutboundCall,188xxxxxxxx,138xxxxxxxx,138xxxxxxxx,172.xx.xx.xx,188xxxxxxxx,XML,public
46afc984-0abe-11e7-9a56-bbab893a85bc,outbound,2017-03-1711:03:20,1489719800,sofia/internal/188xxxxxxxx@172.xx.xx.xx,CS_EXCHANGE_MEDIA,138xxxxxxxx,138xxxxxxxx,172.xx.xx.xx,188xxxxxxxx,,,XML,public,opus,16000,0,opus,16000,0,,vhost212.test.quality,188xxxxxxxx@172.xx.xx.xx,,ACTIVE,OutboundCall,188xxxxxxxx,SEND,46a38a98-0abe-11e7-9a47-bbab893a85bc,138xxxxxxxx,138xxxxxxxx,138xxxxxxxx,138xxxxxxxx,172.xx.xx.xx,188xxxxxxxx,XML,public

【定位过程】

1. 从回显信息中可以看出该会话是由138xxxxxxxx发起的，被叫用户是188xxxxxxxx。根据之前的经验，可能原因是线程死锁、死循环

2. 为不影响测试环境正常使用，gcore了一个core文件进行调试

gdb freeswitch core.xxx
(gdb) thread apply all bt

3. 从众多线程中找到呼叫主线程(LWP 338)

Thread 47 (Thread 0x7f3c89c96700 (LWP 338)):
#0  0x0000003211203f94 in clock_nanosleep () from /lib64/librt.so.1
#1  0x00007f3d473230fb in do_sleep (t=<value optimized out>) at src/switch_time.c:173
#2  0x00007f3d472e7b35 in switch_ivr_multi_threaded_bridge (session=0x7f3c94063858, peer_session=0x7f3ce0095d68, input_call