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