Summary:	ASTERISK-25617: Asterisk 11 segfaults in pj_stun_session_on_rx_pkt
Reporter:	Jeremy Lainé (sharky)	Labels:
Date Opened:	2015-12-08 10:26:45.000-0600	Date Closed:	2015-12-28 09:35:17.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:
Versions:	11.13.1 11.20.0	Frequency of Occurrence
Related Issues:	duplicates ASTERISK-25275 A11 SIGSEGV from pjnpath check_cached_response (ast_rtcp_read -> pj_stun_session_on_rx_pkt)
Environment:		Attachments:	( 0) ast-crash-backtrace.txt
Description:	I am observing several segfaults per day which all have the same backtrace, ending in pj_stun_session_on_rx_pkt. I initially observed these crashes with 11.13.1, but have also observed the same crashes with 11.20.0. This may be the same root cause as ASTERISK-25275.
Comments:	By: Asterisk Team (asteriskteam) 2015-12-08 10:26:47.549-0600 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: Jeremy Lainé (sharky) 2015-12-08 12:22:50.922-0600 Some additional context information : - the backtraces always point to calls over WebRTC - the crashes started appearing in the past week, during which time I made no changes to my asterisk setup. What did change on the other hand is that Chrome 47 was released, and the crashes occur on calls initiated from Chrome 47. Not sure whether it's a coincidence or a real lead. By: Rusty Newton (rnewton) 2015-12-09 17:42:02.504-0600 Thank you for the crash report. However, we need more information to investigate the crash. Please provide: 1. A backtrace generated from a core dump using the instructions provided on the Asterisk wiki [1]. 2. Specific steps taken that lead to the crash. 3. All configuration information necesary to reproduce the crash. Thanks! [1]: https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Rusty Newton (rnewton) 2015-12-09 17:45:05.817-0600 Jeremy can you get a trace following the instructions above? Specifically with DONT_OPTIMIZE and BETTER_BACKTRACES compiler flags. If possible please include a debug log that correlates with the crash.(verbose, debug, warning, notice, error) https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Jeremy Lainé (sharky) 2015-12-10 01:27:47.538-0600 Hi Rusty, BETTER_BACKTRACES was enabled but not DONT_OPTIMIZE. I have captured another backtrace built with -g0 but strangely there are still some <optimized out>. I also have a log with verbose = 5, debug = 5 and sip debug = on, but I'd rather not have it on the public internet, how can I get them to you? Jeremy By: Rusty Newton (rnewton) 2015-12-21 18:37:07.892-0600 I've received your mail and I'm sharing the traces and logs with [~jcolp] to get his opinion. By: Rusty Newton (rnewton) 2015-12-22 17:46:20.167-0600 We don't have a lot to go on so far. There are some other fixes going in that *could* be somewhat related to this issue. Jeremy can you provide data on concurrent SIP session count when the crashes occur? By: Jeremy Lainé (sharky) 2015-12-23 02:11:45.576-0600 I have seen the crashes occur with very few concurrent calls (~ 5), so load did not seem to be a factor. I still have the core dumps, is there a variable I can query to extract the info you want? By: Rusty Newton (rnewton) 2015-12-28 09:35:17.281-0600 No there isn't. However, Josh has identified this issue as a duplicate of ASTERISK-25275 so I'm going to close this out in favor of focus on that issue. Please follow along and comment on that issue. Dade appears to be making some progress there.