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:24Date Closed:2008-10-06 10:47:32
Versions:Frequency of
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.


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.

(gdb) continue
[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
(gdb) bt
#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

Repository: asterisk
Revision: 146643

U   branches/1.4/channels/chan_dahdi.c

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