Aha, thank you. I'm sorry I violated protocol here; I just haven't been closely involved with the project before and didn't RTFM / grok the established folklore how to handle these things. On 01/02/2016 03:29 PM, Ken Rice wrote:
Bug Reports go to Jira
https://freeswitch.org/confluence/display/FREESWITCH/Reporting+Bugs+to+JIRA
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Alex Balashov Sent: Saturday, January 2, 2016 2:19 PM To: freeswitch-dev@lists.freeswitch.org Subject: [Freeswitch-dev] Crash in v1.6.5
Hi,
I'm running v1.6.5:70b8c17, and recently ran into this crash scenario:
(gdb) where #0 switch_core_session_get_channel (session=0x0) at src/switch_core_session.c:1357 #1 0x00007f955ec53ce9 in sofia_update_callee_id (session=0x0, profile=0x1a7ce80, sip=0x7f940c20b728, send=SWITCH_TRUE) at sofia.c:1086 #2 0x00007f955ec59e55 in our_sofia_event_callback (event=nua_i_update, status=200, phrase=0x7f9525d82270 "OK", nua=0x7f953c0120e0, profile=0x1a7ce80, nh=0x7f944fc705a0, sofia_private=0x7f944ef34460, sip=0x7f940c20b728, de=0x7f953c012d40, tags=0x7f9525d82260) at sofia.c:1594 #3 0x00007f955ec5f4fb in sofia_process_dispatch_event (dep=<value optimized out>) at sofia.c:1983 #4 0x00007f955ec60266 in sofia_msg_thread_run (thread=<value optimized out>, obj=0x7f955ebf5ad8) at sofia.c:2031 #5 0x00007f95625f899b in dummy_worker (opaque=0x1a732d0) at threadproc/unix/thread.c:151 #6 0x00007f95617a2a51 in start_thread () from /lib64/libpthread.so.0 #7 0x0000003acfae893d in clone () from /lib64/libc.so.6
Specifically, the crash was on an assertion that tried to dereference a null session pointer:
#0 switch_core_session_get_channel (session=0x0) at src/switch_core_session.c:1357 1357 switch_assert(session->channel);
However, while I am a C programmer, I don't know the first thing about FS internals and thus don't know what else to look for in this core dump so as to make a useful report. My assumption is that a check for NULL session pointer somewhere in frames 0/1 isn't really an adequate compensatory mechanism because the root of the problem lies elsewhere.
I did manage to track down the definition of Sofia's 'sip_t' structure and, it looks to me like this happened while either generating a 200 OK response to an UPDATE request:
(gdb) print sip->sip_request->rq_method $1 = sip_method_update
And it doesn't appear to be in the course of processing a reply, because the status substructure seems blank:
(gdb) print sip->sip_status $2 = (sip_status_t *) 0x0
However, I don't know how to get at the raw message buffer of the UPDATE request.
Any help would be appreciated!
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/