|Summary:||ASTERISK-12774: Joining a MeetMe conference and hanging up shortly after results in SIGSEGV|
|Reporter:||Jeff Gehlbach (jeffg)||Labels:|
|Date Opened:||2008-09-24 20:08:24||Date Closed:||2008-10-06 10:47:32|
|Environment:||Attachments:||( 0) issue_13555.patch|
( 1) meetmesegv-btfull.txt
( 2) meetmesegv-btshort.txt
|Description:||In my 1.6.0-rc6 installation, if a user joins a conference and then hangs up shortly afterward (i.e. during the only-person announcement or during or shortly after the join chime), Asterisk takes a SIGSEGV to the head. Sometimes I can reproduce this on the first try, sometimes it takes two or three consecutive quick join-hangup to reproduce the issue. It seems to occur regardless of whether I enter MeetMe with no arguments or with a conference ID and PIN specified.|
I'm running almost exclusively SIP on this system, haven't tried to reproduce issue with any other technologies. Timing source is a TDM410P, crash happens with dahdi-linux 2.0.0rc4 and trunk.
****** ADDITIONAL INFORMATION ******
Will attach a full trace from strace.
|Comments:||By: Jeff Gehlbach (jeffg) 2008-09-24 20:10:19|
Full trace generated by su-ing to the Asterisk user and running strace -o meetmesegv.txt /opt/asterisk/sbin/asterisk -vvvc
By: Sean Bright (seanbright) 2008-09-24 20:29:16
Spoke with jeffg on #asterisk-dev, he is going to attach a backtrace in the next day or so, so please don't close.
By: Jeff Gehlbach (jeffg) 2008-09-24 20:40:50
Here's a full backtrace from gdb. Despite rebuilding with DONT_OPTIMIZE and running Asterisk with the -g flag, I can't get a core out of it, but I'm able to attach gdb to the running process.
[New Thread 1081358672 (LWP 7672)]
[Thread 1081358672 (LWP 7672) exited]
[New Thread 1081358672 (LWP 7673)]
[Thread 1081358672 (LWP 7673) exited]
[New Thread 1081358672 (LWP 7674)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1081358672 (LWP 7674)]
0x00002b3c8834c0ca in pthread_rwlock_wrlock () from /lib/libpthread.so.0
#0 0x00002b3c8834c0ca in pthread_rwlock_wrlock () from /lib/libpthread.so.0
#1 0x0000000000474c5c in ast_rwlock_wrlock (prwlock=0x2108a63be8) at /home/jeffg/wc/asterisk-1.6.0-rc6/include/asterisk/lock.h:1132
#2 0x0000000000474d0d in ast_event_unsubscribe (sub=0xa29930) at event.c:355
#3 0x00002aaac006275e in destroy_dahdi_pvt (pvt=0x4073e240) at chan_dahdi.c:2770
#4 0x00002aaac006290a in destroy_channel (prev=0x0, cur=0xa11530, now=0) at chan_dahdi.c:2812
ASTERISK-1 0x00002aaac00640a9 in dahdi_hangup (ast=0xa12880) at chan_dahdi.c:3341
ASTERISK-2 0x000000000044ab88 in ast_hangup (chan=0xa12880) at channel.c:1638
ASTERISK-3 0x00002aaab1824076 in conf_free (conf=0xa549c0) at app_meetme.c:1352
ASTERISK-4 0x00002aaab18245cb in dispose_conf (conf=0xa549c0) at app_meetme.c:1455
ASTERISK-5 0x00002aaab182c56e in conf_exec (chan=0xa53980, data=0x40740d80) at app_meetme.c:3197
ASTERISK-6 0x00000000004aac30 in pbx_exec (c=0xa53980, app=0x910eb0, data=0x40740d80) at pbx.c:944
ASTERISK-7 0x00000000004b22db in pbx_extension_helper (c=0xa53980, con=0x0, context=0xa53bd8 "opennmsgroup-trusted", exten=0xa53c28 "scrum", priority=1, label=0x0,
callerid=0xa4f7d0 "7754", action=E_SPAWN, found=0x40742f14, combined_find_spawn=1) at pbx.c:3113
ASTERISK-8 0x00000000004b3860 in ast_spawn_extension (c=0xa53980, context=0xa53bd8 "opennmsgroup-trusted", exten=0xa53c28 "scrum", priority=1,
callerid=0xa4f7d0 "7754", found=0x40742f14, combined_find_spawn=1) at pbx.c:3604
ASTERISK-9 0x00000000004b3fa2 in __ast_pbx_run (c=0xa53980) at pbx.c:3690
ASTERISK-10 0x00000000004b5325 in pbx_thread (data=0xa53980) at pbx.c:3954
ASTERISK-11 0x0000000000506b61 in dummy_start (data=0xa29950) at utils.c:917
ASTERISK-12 0x00002b3c88348317 in start_thread () from /lib/libpthread.so.0
ASTERISK-13 0x00002b3c87eb5d5d in clone () from /lib/libc.so.6
ASTERISK-14 0x0000000000000000 in ?? ()
Hope this is helpful.
By: Kevin P. Fleming (kpfleming) 2008-09-28 09:17:36
It would appear that there is some configuration data 'leaking' from the last channel you have configured in chan_dahdi.conf into the pseudo channel used by app_meetme; please try the attached patch which attempts to resolve this situation.
By: Jeff Gehlbach (jeffg) 2008-10-04 12:00:01
After upgrading DAHDI and tools to 2.0.0-final and Asterisk to 1.6.0-final I verified continued reproducibility of this issue. I then stopped Asterisk, applied Kevin's patch and did a bininstall, started Asterisk again, and was unable to reproduce this problem. Will continue to monitor the system, but I believe that fixed it!
By: Digium Subversion (svnbot) 2008-10-06 10:47:29
r146643 | kpfleming | 2008-10-06 10:47:28 -0500 (Mon, 06 Oct 2008) | 8 lines
ensure that the private structure for pseudo channels is created without 'leaking' configuration data from other configured channels
(closes issue ASTERISK-12774)
Reported by: jeffg
issue_13555.patch uploaded by kpfleming (license 421)
Tested by: jeffg