Summary:	ASTERISK-23577: res_rtp_asterisk: Crash in ast_rtp_on_turn_rtp_state when RTP instance is NULL
Reporter:	Jay Jideliov (jideliov)	Labels:
Date Opened:	2014-04-02 15:17:33	Date Closed:	2014-09-16 06:12:38
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_rtp_asterisk
Versions:	11.9.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt
Description:	Hello Everyone, We have started testing 11.9.0 rc1 as soon as it came out, and have found a significant issue that causes Asterisk to crash. This has appeared on: DISTRIB_ID=Ubuntu DISTRIB_RELEASE=13.10 Linux temp 3.11.0-18-generic #32-Ubuntu SMP2014 x86_64 x86_64 x86_64 GNU/Linux Asterisk logs show nothing. Here's the kern.log: {noformat} Apr  2 15:37:41 temp kernel: [1990904.032131] asterisk[7267]: segfault at 2640 ip 00007faa186f6f74 sp 00007fa9f7ffe3c0 error 4 in libpthread-2.17.so[7faa186ed000+17000] Apr  2 15:45:06 temp kernel: [1991349.344191] asterisk[7724]: segfault at 2640 ip 00007f1bcb77ef74 sp 00007f1bab04d3c0 error 4 in libpthread-2.17.so[7f1bcb775000+17000] Apr  2 16:02:51 temp kernel: [1992413.920139] asterisk[8496]: segfault at 2640 ip 00007f2c5a581f74 sp 00007f2c39f353c0 error 4 in libpthread-2.17.so[7f2c5a578000+17000] {noformat} We have also tried re-compiling Asterisk with DONT_OPTIMIZE compiler flag, still get the same result. Please advise.
Comments:	By: Richard Mudgett (rmudgett) 2014-04-02 15:30:51.190-0500 Thank you for your bug report. In order to move your issue forward, we require a backtrace[1] from the core file produced after the crash. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then: make install After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Richard Mudgett (rmudgett) 2014-04-02 15:34:52.953-0500 This issue might be related: ASTERISK-23559 By: Corey Farrell (coreyfarrell) 2014-04-02 16:34:11.617-0500 I don't believe it is related.  It looks like my description of ASTERISK-23559 is lacking, but the missing symbol did not cause a crash.  In all tests that I know of it appeared the missing symbol was gracefully handled, it prevented app_voicemail from loading and logged a message. By: Rusty Newton (rnewton) 2014-04-03 19:04:46.248-0500 Closing since we were not provided with any backtrace, debug or steps for reproduction as per the guidelines. By: Jay Jideliov (jideliov) 2014-04-12 14:02:29.008-0500 I have attached a backtrace for your review. Thanks. By: Matt Jordan (mjordan) 2014-04-14 12:57:03.681-0500 Looks like an ice_worker_thread callback is occurring when the rtp instance pointer is NULL. That's a little strange; it'd be interesting to see how we managed to get the ICE worker thread started when the RTP instance isn't available. The other option would be that the RTP instance is getting blown away and the ICE worker thread is still working. Re-opening since there's enough information here to formulate something. If nothing else, we should probably handle the rtp instance being NULL (In which case there's nothing to do here but bail)