Since it's running through gdb you could get slightly different behaviour, because timing etc is different. Try collecting a coredump of the program while it's frozen using 'gcore' then open that coredump using gdb. You'll be able to inspect the backtrace to find out exactly what FS was running (ie waiting on) while frozen. On 23 June 2014 09:24, mayamatakeshi <mayamatakeshi@gmail.com> wrote:
I am testing latest commit b21f34bffc with CentOS 6.5.
FS gets stuck at this point during startup:
# ./freeswitch -nonat 2014-06-23 17:16:34.231865 [INFO] switch_event.c:670 Activate Eventing Engine. 2014-06-23 17:16:34.232154 [WARNING] switch_event.c:652 Create additional event dispatch thread 0
So I tried to run it under gdb, but when i do 'r -nonat' in the gdb cli, FS doesn't get stuck and starts properly (i get the FS CLI and I am able to execute commands in it).
Any idea why would this be?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org