Summary:	ASTERISK-21751: Asterisk crashes with segmentation fault when trying to do a pickup with INVITE with Replaces
Reporter:	Morten Isaksen (misaksen)	Labels:
Date Opened:	2013-05-02 06:03:56	Date Closed:	2013-11-10 19:13:59.000-0600
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General Channels/General
Versions:	11.1.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux linux01.uni-tel.local 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux	Attachments:	( 0) asterisk_backtrace.txt ( 1) asterisk_backtrace_new.txt ( 2) pickup.pcap
Description:	25980712 calls 200. 214 tries to pickup call to 200. This gives a segmentation fault with a core dump. Backtrace is attached with a SIP PCAP dump.
Comments:	By: Morten Isaksen (misaksen) 2013-05-02 06:04:35.764-0500 Backtrace By: Morten Isaksen (misaksen) 2013-05-02 06:05:06.932-0500 SIP PCAP dump By: Morten Isaksen (misaksen) 2013-05-02 06:06:57.953-0500 We have also tested with Asterisk 11.3.0 and it also gives a segmentation fault. By: Morten Isaksen (misaksen) 2013-05-02 06:12:45.395-0500 We have just tested Asterisk 1.8.21.0 which does not have this problem. By: Richard Mudgett (rmudgett) 2013-05-02 12:14:02.329-0500 Thank you for your bug report. The backtrace you have supplied is optimized which usually makes it difficult to find the problem. 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: Morten Isaksen (misaksen) 2013-05-03 04:57:45.434-0500 Un optimized backtrace from 11.3.0 By: Rusty Newton (rnewton) 2013-05-08 14:07:25.118-0500 @Morten You say this happens in 11.3.0, but not 1.8.21.0.  Did you use identical configuration between the two? By: Morten Isaksen (misaksen) 2013-05-08 14:09:38.367-0500 Yes, same configuration. By: Matt Jordan (mjordan) 2013-05-09 10:28:46.831-0500 That would make sense, since it's crashing when attempting to set the hangup cause information (part of who hung up). What's strange is that the {{ao2_container}} that stores this should be created on channel creation and never disposed of, but the backtrace shows that the container is NULL. By: Olle Johansson (oej) 2013-06-28 09:03:01.253-0500 What's the status of this issue - anyone taking a look at it? /O By: Matt Jordan (mjordan) 2013-06-28 09:09:14.718-0500 Not yet, but it is on the queue. By: Joshua C. Colp (jcolp) 2013-10-25 10:27:48.395-0500 I've tried to lab this up using the provided information across all versions provided without success. Can you please also provide the complete Asterisk console output with debug when this occurs so I can see the more accurate flow of things internally? By: Matt Jordan (mjordan) 2013-11-10 19:13:48.714-0600 Thank you for the bug report. However I am unable to reproduce this issue. We are now going to close this report - please feel free to reopen when you have more information at hand.