[Home]

Summary:ASTERISK-22474: res_pjsip / res_pjsip_session assertions and segfault
Reporter:Corey Farrell (coreyfarrell)Labels:
Date Opened:2013-09-05 18:00:34Date Closed:2013-09-23 07:02:55
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip Resources/res_pjsip_session
Versions:12.0.0-alpha1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) cli-3.conf
( 1) gdb-log-1
( 2) gdb-log-2
( 3) gdb-log-3
( 4) gdb-log-3.txt
( 5) granular_rollback.diff
( 6) menuselect.makeopts
( 7) modules-1.conf
( 8) modules-2.conf
( 9) modules-3.conf
Description:It is relatively easy to cause a crash with res_pjsip.  I've attached numbered modules.conf for each test, and cli.conf for the 3rd test.  gdb-logs where obtained by running:
{noformat}
gdb --batch -ex 'r' -ex 'bt' -ex 'thread apply all bt' -ex 'thread apply all bt full' asterisk 2>&1 | tee gdb-log
{noformat}

# use modules-1.conf.  Causes segfault in ast_threadpool_push due to pool==NULL.
# use modules-2.conf.  Causes assert in pjsip_endpt_unregister_module when attempting to cancel res_pjsip load.
# use modules-3.conf and cli-3.conf.  Causes assert in pjsip_endpt_register_module when loading res_pjsip_session for second time.

Additional note: res_pjsip MODULEINFO lists res_sorcery_config as the only required module.  res_sorcery_astdb and res_sorcery_memory should probably be listed as well.
Comments:By: Joshua C. Colp (jcolp) 2013-09-05 18:02:42.445-0500

Listing those as requirements won't fix all cases as the sorcery configuration can be overridden. They are simply the defaults.
By: Corey Farrell (coreyfarrell) 2013-09-05 18:03:08.454-0500

Also included menuselect.makeopts incase it matters.
By: Joshua C. Colp (jcolp) 2013-09-05 18:21:24.690-0500

We can't try to rollback everything we've done, as some operations require certain things to exist (that won't) soooo this make things more granular. Give it a try!
By: Corey Farrell (coreyfarrell) 2013-09-05 18:35:26.601-0500

[^granular_rollback.diff] allows test #1 and #2 to run without crashing.
By: Joshua C. Colp (jcolp) 2013-09-13 08:59:06.995-0500

Test #3 is interesting... pjsip is acting as if we haven't unregistered the module, but we have.
By: Corey Farrell (coreyfarrell) 2013-09-14 19:18:54.955-0500

I recompiled pjproject with optimization disabled.  Updated backtrace included in gdb-log-3.txt.  It appears I'm getting a crash due to pjproject internal modules: "mod-invite" and "mod-100rel".  They are registered during load of res_pjsip_session but not unregistered at unload.
By: Joshua C. Colp (jcolp) 2013-09-15 07:58:21.966-0500

Ah yeah, those are pjsip provided and not something we can unregister ourselves. Looks like res_sip_session will not be unloadable.