Summary:	ASTERISK-15906: Asterisk crashes after "Stopped music on hold on DAHDI" (or tranfer to SIP channel may be)
Reporter:	leff (leff)	Labels:
Date Opened:	2010-04-02 05:46:17	Date Closed:	2011-06-07 14:00:53
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Channels/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) gdb.txt
Description:	Crash example: Dial("DAHDI/1", "SIP/xxxx") in new stack    -- Called xxxx    -- SIP/xxxx is ringing    -- SIP/xxxx answered DAHDI/1 -- Started music on hold, class 'default', on DAHDI/1 Dial("SIP/xxxx", "SIP/yyyy") in new stack    -- Called yyyy    -- SIP/yyyy is ringing    -- Stopped music on hold on DAHDI/1 Disconnected from Asterisk server ****** ADDITIONAL INFORMATION ****** The environment: Asterisk 1.4.30 + app_fax patch + CONNECTEDLINE patch. Debian Lenny. There is no possibility to debug (production server) but core dumps. gdb.txt is attached.
Comments:	By: leff (leff) 2010-04-03 00:35:28 Is there enough information to find the bug? I have made the issue as private because of the information inside gdb.txt, so you are welcome to make it public after downloading and deleting gdb.txt attachment from the issue... By: leff (leff) 2010-04-03 02:26:20 Have tried to find the place of crash at gdb's outputs with different core dumps. It comes to the next situation for crash: The call: DAHDI <-> SIP 1 (no matter who initialized the call) SIP 1 transfers DAHDI to SIP 2 making SIP REFER = crash. SIP 1 and SIP 2 are both Polycom phones (firmware version is 3.2.1 if it will help). By: leff (leff) 2010-04-03 05:19:22 Polycom's firmware 3.2.2 changelog has the item into the list of fixes: "54139: Consultative Transfer uses wrong URI on REFER. Issue introduced in SIP 3.2.0." There are a lot of phones at this installation, so I should be sure before making upgrade of phones. Can "wrong URI on REFER" lead to Asterisk crash? By: leff (leff) 2010-04-03 13:53:31 Issue is ok to close - the problem is in patch from here: https://issues.asterisk.org/view.php?id=8824#118065 I will reopen issue with this patch. Thank you. By: Leif Madsen (lmadsen) 2010-04-06 09:29:56 Actually leaving this issue open is the better option. I'll just mark these are related to 8824. By: Leif Madsen (lmadsen) 2010-04-06 09:42:41 Your backtrace also seems to be created from a system without DONT_OPTIMIZE enabled which makes it less than useful. A better backtrace (useful) will be generated upon crash if you have DONT_OPTIMIZE enabled within menuselect within the Compiler Flags section. By: leff (leff) 2010-04-06 13:49:21 The installation is servicing 300+ users already... There is no possibility for test ( I have just disabled this feature to have no crashes, but it is really needed, because of other systems have it ). Do you have the possibility to reproduce the crash (1.4.30+connectedline and make attended transfer)? By: Leif Madsen (lmadsen) 2010-04-15 10:35:33 I have no possibility to reproduce this issue. Either you'll need to reproduce the issue on a development/lab system, or we'll need to close the issue. By: Leif Madsen (lmadsen) 2010-04-30 12:01:02 Suspending this issue for now.