Summary:	ASTERISK-19730: Stack overflow in chan_sip when destroying mwipvt
Reporter:	Ross Beer (rossbeer)	Labels:
Date Opened:	2012-04-17 04:16:11	Date Closed:	2015-03-21 16:01:00
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	1.8.11.0	Frequency of Occurrence	Occasional
Related Issues:
Environment:	Cent OS 5.5	Attachments:	( 0) backtrace.txt ( 1) backtrace-02052012.txt ( 2) backtrace-070512.txt ( 3) backtrace2012-04-12.txt ( 4) backtrace2012-04-17.txt ( 5) backtrace-20120514.txt
Description:	After running for a few days asterisk crashes. Looking at the backtraces there are a lot of 'address out of bound' messages which could be causing the issue. These appear to be related to the chan_sip code. I'm not sure if this is related to presence, subscribe and notify, as I reported a similar issue a while back that was resolved.
Comments:	By: David Woolley (davidw) 2012-04-17 05:44:20.582-0500 The first is an abort in the memory manager.  That generally indicates a corruption of the heap and is often preceded by error messages about locking failures (especially if you have thread debugging enabled). I note that both backtraces breach the bug reporting guidelines, as they were produced from optimised binaries. By: Ross Beer (rossbeer) 2012-04-17 07:03:37.702-0500 I'll re-compile without optimisation, once a crash occurrences I will post the backtrace. I was aware of this but hoped that they would be a starting point while waiting for the next crash. By: Matt Jordan (mjordan) 2012-04-17 08:26:11.895-0500 Can you provide a debug log as well that illustrates the crash?  It appears as if the mwipvt got set incorrectly. By: Matt Jordan (mjordan) 2012-05-02 08:34:51.635-0500 Ross: did you ever get another crash? By: Sébastien Couture (sysreq) 2012-05-02 10:28:10.703-0500 I've had Asterisk crash for what seems to be the same reason this morning. This is under 1.8.10.1, but I've had the same issue under 1.8.11.0 last week -- I downgraded in the hopes that it could be a regression bug in the latest release only. By: Sébastien Couture (sysreq) 2012-05-07 09:15:16.452-0500 I've experienced yet another crash this morning where the destroying of 'mwipvt' seems to be at fault. I've attached a full backtrace. By: rayjay (rayjay) 2012-05-07 15:33:20.037-0500 We have also been experiencing crashes in 1.8.11.0 - around 5 so far.  Our backtrace looks very similar to those included already in this case so I expect it is the same issue we are seeing?  Can this issue be escalated as this is a real issue for us now with 5 crashes in 2 weeks? If it is related to MWI is there a way we can limit the damage by disabling any features in the SIP channel relating to MWI? By: Matt Jordan (mjordan) 2012-05-07 16:47:47.664-0500 So, as I request from Ross, a DEBUG log that starts just prior to the beginning of the recursive destruction of the mwipvt would be very useful.  If someone who's having this problem would like to attach it, that would help get this issue debugged. By: Ross Beer (rossbeer) 2012-05-14 04:26:38.497-0500 I've uploaded a bt for the latest crash. It does appear to be with voicemail. As far as I can tell it is caused when a message is recorded. I am using ODBC voicemail. I notice that a user tried to forward the message to another mailbox even though sendvoicemail is set to 'no', the mailbox entered was invalid. Therefore I believe the is also a bug related to 'sendvoicemail=no' as this shouldn't allow the user to use this feature. By: Ross Beer (rossbeer) 2012-05-20 05:11:08.661-0500 In addition to my previous post, I've looked through other thickets and could this be related to mysql realtime and ODBC is now the preferred? By: Matt Jordan (mjordan) 2012-05-21 09:01:41.713-0500 Ross: Your latest backtrace is not the same issue.  It does not indicate a stack overflow situation, nor does it occur in the same section of code.  Please open a new issue with that particular crash, and attach the backtrace to it. Furthermore, ODBC voicemail uses its own ODBC mechanisms (in conjunction with res_odbc) to perform the database related operations.  It does not use the MySQL realtime driver.  If, however, you're actually using realtime Voicemail, and your realtime driver is the MySQL driver, then yes, that is not a configuration that is recommended. Matt By: Ross Beer (rossbeer) 2012-05-30 14:33:49.870-0500 Could this issue be caused by ASTERISK-19827 which has been resolved in the Asterisk 1.8.13.0-rc2 release? ODBC realtime is now also in use. By: Matt Jordan (mjordan) 2012-05-30 15:42:44.588-0500 Ross: I'd be surprised if it was caused by that, given that the issue there was a dereference of a NULL pointer.  You're more then welcome to try the patch and see if it resolves it however.