Summary:	ASTERISK-05197: Consultative transfers let * crash (malloc() problem)
Reporter:	Joerg Wolf (jwg)	Labels:
Date Opened:	2005-09-30 07:06:37	Date Closed:	2005-10-27 18:09:12
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) logs.tar
Description:	Hi, setup is as follows: - asterisk CVS HEAD built by root@troubadisk on a i686 running Linux on 2005-09-29 07:22:08 UTC - Xten SIP clients, ISDN trunk (chan_misdn), H.323 trunk - AMP generated dialplan - app_queue with callback agents - cdr_addon_mysql for storing cdrs After doing a consultative transfer using the transfer button on the Xten SIP clients, asterisk will crash sooner or later. It seems that something goes wrong when information are copied while bridging the channels takes place: the segfaults always occur in subsequent mallocs(). I suspect that the nested macros which are prematurely finished (exiting non-zero) on the ZOMBIE channels cause the problems. I'm chasing this bug for weeks now but can't track it down further. My agents need the transfer feature necessarily... Let me know if more information/log/etc. are required. Thanks! Jörg ****** ADDITIONAL INFORMATION ****** I attached * console output, * messages (full), gdb output, config files. The relevant call went like this: - SIP/9999 called mISDN/1/207 - call put on hold - SIP/9999 called H323/208 - Transfer button hit on SIP/9999 - call has been transfer, i.e. 207 and 208 were connected. - * crashed after one or two subsequent calls As a hint: the cdr of one of the partial calls contains a corrupted CLID: 'Øj @Øj @trator\" <9999>'
Comments:	By: Olle Johansson (oej) 2005-09-30 10:44:42 That code will soon be replaced by new code, largely rewritten. By: Michael Jerris (mikej) 2005-09-30 11:15:56 Can you confirm if this is a duplicate of ASTERISK-5015 or not by removing the cdr calls?  It sounds like it may be. By: Joerg Wolf (jwg) 2005-09-30 12:31:34 Yeah, seems to be at least similar. I still tried to remove calling the hangup-call macro (for all channels or for ZOMBIE-channels only), but the segfaults were still there. Seems to me that accessing the cdrs after the transfer will reveal, but not cause the problem. By: Olle Johansson (oej) 2005-10-20 02:20:33 Any additional modules in your server, like mp3 support? By: Joerg Wolf (jwg) 2005-10-20 03:12:59 @oej: If you are asking wether I load app_mp3.so: I tried it with and without loading app_mp3.so, makes no difference, the problem is still there. Meanwhile, I'm testing with a stripped down dialing plan (no AMP, no agents, no queues etc., just 3 Xten SIP clients) with the same result: as soon as I use those ResetCDR(w)... commands asterisk will crash sooner or later after a transfer. Please let me know if you need more information... Thanx! By: Olle Johansson (oej) 2005-10-20 04:03:48 Is it only when you use resetcdr *after* a SIP transfer or for any call? By: Joerg Wolf (jwg) 2005-10-20 04:48:04 The problem occurs sooner or later after a SIP transfer, there's no crash when doing simple calls only. By: Olle Johansson (oej) 2005-10-20 04:51:14 So we need to look into the cdr handling of SIP transfers then. Righto. Thanks for the feedback. By: Joerg Wolf (jwg) 2005-10-26 07:35:25 oej: yes, after spending some more time and adding a number of lines with debug information, I'm pretty sure that the cdr handling causes the problem. (btw: the problem still persists in 1.2beta...). Please let me know if I can help in some way to find the problem. I didn't fully understand how all this masquerading etc. works, but probably I could do some testing or so... Thanx! By: Joerg Wolf (jwg) 2005-10-27 08:36:33 Good news: I found the cause for the segfaults, see http://bugs.digium.com/view.php?id=5525 Less good news: cdrs are not accurate, i.e. src and dst do not really reflect the scenarios. There are 3 cdrs as I would expect, but src/dst are wrong and depending on which party hangs up A. scenario: a -> b, a -> c, c transferred to b, b hangs up all 3 cdrs show the same: src=b, dst=c B. scenario: a->b, a->c, c transferred to b, c hangs up 1. src=a,dst=b 2. src=a,dst=c 3. src=a,dst=b I would expect (no matter which party hangs up) something like: 1. src=a, dst=b 2. src=a, dst=c 3. src=b, dst=c (or vice versa) By: Mark Spencer (markster) 2005-10-27 18:07:23 Fixed in CVS head