Summary: | ASTERISK-26545: Asterisk core dump while sending MWI with chan_sip, (in sip_send_mwi_to_peer at chan_sip.c) | ||
Reporter: | Leandro Dardini (ldardini) | Labels: | |
Date Opened: | 2016-11-01 11:42:03 | Date Closed: | |
Priority: | Critical | Regression? | |
Status: | Open/New | Components: | Channels/chan_sip/General |
Versions: | 13.12.1 13.13.1 | Frequency of Occurrence | Occasional |
Related Issues: | |||
Environment: | CentOS 6.8 64bit Mysql 5.1 | Attachments: | ( 0) backtrace-Ahmed.txt ( 1) backtrace-Robert.txt ( 2) frack.txt ( 3) frack2.txt ( 4) frack3-betterbacktraces.txt |
Description: | I started upgrading servers from 13.2.0 to 13.12.1 and some started to crash for segmentation fault. Function involved seems always sip_send_mwi_to_peer
| ||
Comments: | By: Asterisk Team (asteriskteam) 2016-11-01 11:42:03.558-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Leandro Dardini (ldardini) 2016-11-01 11:43:45.279-0500 Backtrace-Ahmed.txt was fine, but backtrace-Robert.txt was captured with the server not configured with "DONT_OPTIMIZE and BETTER_BACKTRACES". By: Rusty Newton (rnewton) 2016-11-02 15:25:38.080-0500 Leandro do you have logs that accompanied the crash? Preferably with the SIP traces included? Thanks! By: Leandro Dardini (ldardini) 2016-11-02 16:27:22.357-0500 Unfortunately I have not much... just asterisk logs. Servers were quite busy and I didn't find a way to reproduce the crash... it just happen. However asterisk verbose log has some messages I have never seen before... FRACK! Both servers crashed in the middle of the day, but the second one (Robert backtrace) started to throw "FRACK" messages even during the night , when no activity was taking place. I have attached both /var/log/asterisk/full messages. I checked other servers running 13.12.1 and I can find the FRACK messages on each of them (apart from really quiet servers), but no crashes. I noticed FRACK messages were thrown even with asterisk 13.12.0-rc1 If you need me to run a customized version to get more info around the FRACK message or whatever test you may need, I am available. By: Leandro Dardini (ldardini) 2016-11-02 16:27:51.605-0500 Frack messages in the logs By: Richard Mudgett (rmudgett) 2016-11-02 17:36:05.782-0500 Those FRACK messages also come with a stack probe backtrace to show where the bad ao2 object reference is being done. Unfortunately, those backtraces aren't very useful because you don't have BETTER_BACKTRACES enabled (DONT_OPTIMIZE would also be a plus). Asterisk has had "bad magic number" and "user_data is NULL" ERROR messages for quite awhile, but only recently were they changed to get a backtrace for where they are happening in the code. It has always indicated a bug when you get the "bad magic number" or "user_data is NULL" messages. The crashes may be caused by the fix for ASTERISK-25468 By: Leandro Dardini (ldardini) 2016-11-02 18:49:23.048-0500 Yes, it is possible the bug was introduced with the fix for ASTERISK-25468. I have attached few FRACK messages along with the "better backtrack" By: Leandro Dardini (ldardini) 2016-11-02 18:52:52.336-0500 This time with better backtraces enabled By: Daniel Denson (dandenson) 2017-01-09 13:47:12.881-0600 Has there been any progress with this? I'm having this issue with newer builds. I'm trying to get opus support but this bug effects all versions that support opus. By: Joshua C. Colp (jcolp) 2017-01-09 15:05:56.237-0600 Any progress will be posted here. As there have been no comments it does not appear anyone is currently working on this problem. |