Summary:	ASTERISK-15076: Asterisk Crash after SIP Transfer
Reporter:	Xin Ye (xinyer)	Labels:
Date Opened:	2009-11-04 02:31:14.000-0600	Date Closed:	2009-12-07 12:18:57.000-0600
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) backtrace21565.txt ( 1) backtrace31178.txt
Description:	Asterisk crashes without any error, the last two lines of log before crash are: VERBOSE[2998] logger.c:     -- SIP/8083-08e16f60 is ringing DEBUG[1891] chan_sip.c: SIP transfer: Succeeded to masquerade channels. Similar error was reported in the following thread: https://issues.asterisk.org/bug_view_advanced_page.php?bug_id=13256#93893 but it is closed. This happened to me twice today, but it works fine for the last one week. I couldn't reproduce the crash.
Comments:	By: Leif Madsen (lmadsen) 2009-11-04 08:37:41.000-0600 Additional information is required in order to move this forward. 1) we need a backtrace from the crash which doesn't have optimizations. Please see doc/backtrace.txt of your Asterisk source for information on how to provide this information. 2) What is the console output prior to the crash? I'd like to see if this is related to a SIP transfer from a queue as that issue is Ready for Review and you could test that patch By: Xin Ye (xinyer) 2009-11-04 22:47:52.000-0600 Dear Imadsen, 1) My server did not generate any core file, and I'm using safe_asterisk. Do I need to reinstall asterisk with DONT_OPTIMIZE flag? 2) The last output at the console show that there was an attended transfer. The call was from one SIP extension to another SIP extension, then when one of the user tried to transfer to a third SIP extension the server crash. There is no error message left in the log. By: Leif Madsen (lmadsen) 2009-11-05 09:31:34.000-0600 DONT_OPTIMIZE will give the appropriate output from the crash. The core file I believe should be in the /tmp/ folder, as I think that's where safe_asterisk should put it. The console output will be far more useful than just your description of the console output. Additionally, the dialplan you're using and the exact steps to reproduce this issue would also be handy. By: Bereterbide Marcelo (marhbere) 2009-11-09 12:40:24.000-0600 I guess that 1.4.26.2 doesn´t applied the patch: https://issues.asterisk.org/view.php?id=15845 By: Leif Madsen (lmadsen) 2009-11-09 15:15:02.000-0600 No, as 1.4.26.2 is a security release only, as is clearly stated in the release announcement, and by reviewing the ChangeLog. Bug fixes are currently being evaluated in a release candidate as 1.4.27-rc2, released today. By: Xin Ye (xinyer) 2009-11-09 22:43:51.000-0600 Sorry, I didn't get a chance to recompile asterisk yet, because my server is already in use. Here is the log of yesterday when the server stopped again: [Nov  9 14:11:15] VERBOSE[12477] logger.c:     -- Executing [6124@outgoing:1] AGI("SIP/sg39-08d01028", "getroute.php|null|SG|6124|sg39|1") in new stack [Nov  9 14:11:15] VERBOSE[12477] logger.c:     -- Launched AGI Script /var/lib/asterisk/agi-bin/getroute.php [Nov  9 14:11:15] VERBOSE[12477] logger.c:     -- AGI Script getroute.php completed, returning 0 [Nov  9 14:11:15] VERBOSE[12477] logger.c:     -- Executing [6124@outgoing:2] NoOp("SIP/sg39-08d01028", "SIP/sg41") in new stack [Nov  9 14:11:15] VERBOSE[12477] logger.c:     -- Executing [6124@outgoing:10] Dial("SIP/sg39-08d01028", "SIP/sg41|60|TtWw") in new stack [Nov  9 14:11:15] VERBOSE[12477] logger.c:     -- Called sg41 [Nov  9 14:11:15] VERBOSE[12477] logger.c:     -- SIP/sg41-08cee4c8 is ringing [Nov  9 14:11:16] DEBUG[3145] chan_sip.c: SIP transfer: Succeeded to masquerade channels. -------------------------------- the server crashed a few times already, always after the "SIP transfer: Succeeded to masquerade channels." message. By: John Todd (jtodd) 2009-11-12 15:51:57.000-0600 We really, really need a backtrace.  This sounds like an important issue, but without a BT, it's kind of impossible to solve. By: Xin Ye (xinyer) 2009-11-13 00:37:05.000-0600 I am planning to migrate the server to 1.2 today, then I will recompile with Dont-optimize flag and try to get the bt. It is a production server with 50 over users, just upgraded from 1.2 now must downgrade again. The problem happens not only during transfer, but also simple Exten to exten call. Probably next Monday I will be able to produce the backtrace. By: Leif Madsen (lmadsen) 2009-11-17 07:33:10.000-0600 Just curious if you were able to retrieve those backtraces per the doc/backtrace.txt file in your Asterisk source?  Thanks! By: Xin Ye (xinyer) 2009-11-27 20:43:20.000-0600 I'm sorry, I couldn't reproduce the problem after taking the server out from live environment. I've been trying to make SIP to SIP calls whenever I'm free for the last 2 weeks, but couldn't reproduce the problem. The current files in my /tmp folder was generated with optimized asterisk compilation, it is useless according to the doc/backtrace.txt. By: Leif Madsen (lmadsen) 2009-12-01 13:18:33.000-0600 Not sure where this leaves us other than to wait for it to happen again after you update back to 1.4.x with DONT_OPTIMIZE enabled, or you have the ability to reproduce in the lab... :( By: David Vossel (dvossel) 2009-12-01 17:10:52.000-0600 There were several updates to the SIP transfer code since the 1.4.26.2 release.  There's a good chance this may have been resolved. By: Xin Ye (xinyer) 2009-12-04 00:05:35.000-0600 I'm sorry, I couldn't reproduce the crash. There was about 70 users when the problem happened, but now the server is taken to the lab, just not able to trigger the error anymore. By: Leif Madsen (lmadsen) 2009-12-07 12:18:57.000-0600 OK, I'm going to close this issue for now then, and if you are able to reproduce or provide additional information with a newer version of Asterisk, the please reopen the issue. Thanks! By: Avinoam (avinoash) 2014-01-15 08:52:43.986-0600 Hello. Before I open a new ticket I thought about joining this one. I'm experiencing - what I think might be - the same issue: Every now and then, in a random interval of time and conference calls, the Asterisk(1.4.44) would crash with segfault 11 after a - "chan_sip.c: SIP transfer: Succeeded to masquerade channels". conference crash scenario: A calling in => B answers => B puts A on hold => B calls C => C answers => B joins A into the call => three way conference A, B, C => B leaves the call => crash (randomly) I have attached two back trace files. Could really use some help here... Regards, By: Matt Jordan (mjordan) 2014-01-15 08:58:15.660-0600 Asterisk 1.4.44 is no longer supported, and hasn't been for quite some time. The difference between {{chan_sip}} in Asterisk 1.4.44 and Asterisk 1.8 is enormous, and any bug in Asterisk 1.4.44 in {{chan_sip}} is unlikely to be the same in Asterisk 1.8.