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-0600 | Date Closed: | 2009-02-06 13:30:31.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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 |