|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|
|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 184.108.40.206, but I've had the same issue under 220.127.116.11 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 18.104.22.168 - 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
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.
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 22.214.171.124-rc2 release?
ODBC realtime is now also in use.
By: Matt Jordan (mjordan) 2012-05-30 15:42:44.588-0500
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.