[Home]

Summary:ASTERISK-13442: MeetMe conference crashes Asterisk 95% of the time when the last user hangs up/exits the conference.
Reporter:Anthony Messina (amessina)Labels:
Date Opened:2009-01-24 01:08:01.000-0600Date Closed:2009-02-06 13:30:31.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_meetme
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) gdb.txt
( 1) gdb-DONT_OPTIMIZE-proper.txt
( 2) gdb-NO_OPTIMIZE.txt
( 3) valgrind.txt
Description:I have a TDM400P card in the box and am using Asterisk-1.6.0.5 (Fedora 10 x86_64).  *Almost* every single time the last user exits a MeetMe conference, Asterisk segfaults.

Occasionally, Asterisk does not segfault.  I do not use "safe_asterisk."
Comments:By: Anthony Messina (amessina) 2009-01-24 01:08:42.000-0600

gdb output attached.

By: snuffy (snuffy) 2009-01-24 06:44:22.000-0600

Hello amessina,

Thanks for the gdb output but it appears you may not have recompiled with 'DONT_OPTIMIZE' flag.

If you could upload a gdb backtrace with that flag turned on would be much appreciated

By: Anthony Messina (amessina) 2009-01-24 09:30:54.000-0600

Hmmm, I was hoping that the backtrace as is would be somewhat helpful, as I am running this system with the pre-compiled Fedora 10 x86_64 binaries (with the debuginfo rpm installed).  I do not have another system with the TDM400P installed on which to test a custom build.  Would it be useful to attempt the custom build on another F10 x86_64 system using the dahdi_dummy driver, assuming I can reproduce the result that way?

By: Anthony Messina (amessina) 2009-01-24 21:41:28.000-0600

This issue seems almost exactly the same as 0014282, but the fix for that issue is only related to the i/I options to the MeetMe application.

By: Anthony Messina (amessina) 2009-01-24 23:29:40.000-0600

I have recompiled asterisk using the DONT_OPTIMIZE flag and attached the new backtrace in the gdb-DONT_OPTIMIZE.txt file, though this seems (to me, a non-programmer) to have less info than my original backtrace.

By: Anthony Messina (amessina) 2009-01-25 00:13:51.000-0600

Sorry, please look at the gdb-DONT_OPTIMIZE-proper.txt file (the first one I compiled incorrectly.

By: snuffy (snuffy) 2009-01-25 17:42:40.000-0600

Thanks for the update.
Hopefully a developer can look  into this for you soon

By: Anthony Messina (amessina) 2009-02-05 06:35:13.000-0600

Thanks for acknowledging this bug.  Has anyone been able to look into this.  I'm keeping my system running with DONT_OPTIMIZE as I anticipated that you might need further information, but I'd like to return it to normal operation if the backtrace provided "enough" information to find the root of the problem.

Thanks.

By: Jeff Peeler (jpeeler) 2009-02-05 17:18:10.000-0600

What version is this happening in? Two are mentioned in the original report. I don't immediately see what the problem is from the backtrace. I was hoping I could reproduce it, but haven't been able to do so as of yet. Also, you are passing in sM as options to Meetme?



By: Anthony Messina (amessina) 2009-02-05 17:22:41.000-0600

It has happened in every version of 1.6.0 I have used, including 1.6.0.5 and 1.6.0.5.

If it helps, the users of the conference usually connect via either DAHDi or SIP phones connected directly at this server, or via IAX2/DUNDi from another asterisk server.

The problem happens when the last user in the conference hangs up their phone, whichever connection method is being used.  The backtrace was produced by me using a SIP phone connected directly to this server, entering the conference (with MOH as I was the only user), then hanging up my phone.

By: Anthony Messina (amessina) 2009-02-05 18:30:16.000-0600

Adding valgrind.txt

By: Digium Subversion (svnbot) 2009-02-06 13:28:54.000-0600

Repository: asterisk
Revision: 174041

U   trunk/channels/chan_dahdi.c

------------------------------------------------------------------------
r174041 | file | 2009-02-06 13:28:54 -0600 (Fri, 06 Feb 2009) | 4 lines

Don't subscribe to a mailbox on pseudo channels. It is futile. This solves an issue where duplicated pseudo channels would cause a crash because the first one would unsubscribe and the next one would also try to unsubscribe the same subscription.
(closes issue ASTERISK-13442)
Reported by: amessina

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=174041

By: Digium Subversion (svnbot) 2009-02-06 13:29:42.000-0600

Repository: asterisk
Revision: 174042

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_dahdi.c

------------------------------------------------------------------------
r174042 | file | 2009-02-06 13:29:42 -0600 (Fri, 06 Feb 2009) | 11 lines

Merged revisions 174041 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r174041 | file | 2009-02-06 15:28:53 -0400 (Fri, 06 Feb 2009) | 4 lines
 
 Don't subscribe to a mailbox on pseudo channels. It is futile. This solves an issue where duplicated pseudo channels would cause a crash because the first one would unsubscribe and the next one would also try to unsubscribe the same subscription.
 (closes issue ASTERISK-13442)
 Reported by: amessina
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=174042

By: Digium Subversion (svnbot) 2009-02-06 13:30:30.000-0600

Repository: asterisk
Revision: 174043

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_dahdi.c

------------------------------------------------------------------------
r174043 | file | 2009-02-06 13:30:30 -0600 (Fri, 06 Feb 2009) | 11 lines

Merged revisions 174041 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r174041 | file | 2009-02-06 15:28:53 -0400 (Fri, 06 Feb 2009) | 4 lines
 
 Don't subscribe to a mailbox on pseudo channels. It is futile. This solves an issue where duplicated pseudo channels would cause a crash because the first one would unsubscribe and the next one would also try to unsubscribe the same subscription.
 (closes issue ASTERISK-13442)
 Reported by: amessina
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=174043