Summary:	ASTERISK-08601: Seg.fault when parking a call via an extenension
Reporter:	pluto70 (pluto70)	Labels:
Date Opened:	2007-01-18 03:43:43.000-0600	Date Closed:	2007-06-30 09:19:59
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) bt_full_54290.txt ( 1) bt.txt ( 2) bt_full.txt ( 3) extensions_additional.conf ( 4) extensions.conf ( 5) park_debug.txt ( 6) thread_apply_all_bt.txt ( 7) verbosedebug_54290.txt ( 8) verbosedebug.txt ( 9) verbosedebug50227.txt
Description:	If I try to park a call Asterisk stops with Segfault after the parkslot has been announced.
Comments:	By: Francesco Romano (francesco_r) 2007-01-18 10:50:13.000-0600 The same happens with latest 1.2 SVN, with 1.2.14 is ok. Update: the problem is from revision 50295 (see app_dial.c), reverting to 50294 1.2 branch works well for me. By: pluto70 (pluto70) 2007-01-19 06:00:03.000-0600 Problem gone with 51288 By: Francesco Romano (francesco_r) 2007-01-19 12:18:37.000-0600 Tried now 1.2-r51300, always segfault. By: Bruce Reeves (nortex) 2007-01-25 09:06:28.000-0600 The same thing is happening with 1.4 SVN r51350. I also have this message in the CLI right before the crash. *** glibc detected *** double free or corruption (!prev): 0x0a1a93d8 *** another strange thing is if the called extension has priorities after the dial command then the system races through them and then faults. By: Serge Vecher (serge-v) 2007-01-31 09:24:32.000-0600 francesco_r, nortex: please upload a backtrace from non-optimized build of the latest 1.2 or 1.4 branch. By: Clod Patry (junky) 2007-02-01 00:17:05.000-0600 Also, could ya explain how ya park ur call exactly? same type of channel? a CLI output would be useful. By: Francesco Romano (francesco_r) 2007-02-06 08:58:00.000-0600 I have attached a full bt trace with a CLI output. Thank you. By: Serge Vecher (serge-v) 2007-02-07 11:12:19.000-0600 ok, let's dig into chan_sip a little, since that's what is in use: 1) Prepare test environment (reduce the amount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterisk with the following command:   'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt' 4) Enable SIP transaction logging with the following CLI commands: set debug 4 set verbose 4 sip debug 5) Trim startup information and attach verbosedebug.txt to the issue. By: Francesco Romano (francesco_r) 2007-02-08 05:57:35.000-0600 I have attached the sip debug of the following actions: extension 202 called 201, 201 parked the call, asterisk core dumped. By: Serge Vecher (serge-v) 2007-02-08 10:00:30.000-0600 francesco_r: what modifications have you done to the source? Also, can you please upload a debug file from r 50294 just to see what kind of output does a working revision produce. (upload in uncompressed format please) By: Francesco Romano (francesco_r) 2007-02-08 12:47:28.000-0600 I haven't modified the source code. Today i have upgraded one test machine from 1.2 to 1.4 r53571 and i have always core dump making the same simple procedure. I have tested this with different machines but using the same fresh installed distro: Slackware 11. Tomorrow i'll be back to 1.2 50294 (or 1.4 50294) and i'll post the results. By: Serge Vecher (serge-v) 2007-02-08 15:42:37.000-0600 hmm, your version string suggests that sources were modified. Can you please explain which "same simple procedure" you use to have the core dumped? By: Francesco Romano (francesco_r) 2007-02-09 11:53:42.000-0600 The 'simple procedure' is: 1) Start asterisk 2) 202 call 201 3) 201 park the call 4) asterisk crash.... I have now attached the debug with revision 50227 with these actions: 1) Start asterisk 2) 202 call 201 3) 201 park the call 4) the call is successfully parked 5) 201 call 71 (park extension) 6) 201 hangup 7) stop gracefully asterisk By: Francesco Romano (francesco_r) 2007-02-14 03:58:07.000-0600 I did other tests and... If the callee or the caller park the call with a sip phone native transfer to 70 (park extension) i have no segmentation fault. If the caller park using dtmf digits defined in features.conf i have no segmentation fault. So the problem is only when the called part park with digits and is technology indipendent. I tried this with latest 1.2svn and 1.4svn and with Grandstream GXP2000, Snom 3X0 phones and analog phones connected to zaptel fxs. By: Serge Vecher (serge-v) 2007-02-14 11:08:34.000-0600 ok, last question, please post the extensions.conf entry for 71 => By: Francesco Romano (francesco_r) 2007-02-14 13:55:02.000-0600 I have attached the extensions.conf and extensions_additional.conf generated by freepbx.org gui By: Serge Vecher (serge-v) 2007-02-14 14:24:00.000-0600 ok, I'm a bit confused -- what do you mean by "So the problem is only when the called part park with digits and is technology indipendent."? I specifically don't understand what does "park with digits" mean. Also, your answer "I haven't modified the source code" is not truthful, at least as far verbosedebug.txt is concerned -> there are third party patches, like app_valetparking there, that are not part of official Asterisk distribution. Testing needs to be done with stock Asterisk 1.2.15 tarball. By: Francesco Romano (francesco_r) 2007-02-14 14:57:03.000-0600 Sorry for my jpeg quality english serge-v... You are right, the verbosedebug file i posted was from an installation with a thirdy part module installed (app_valetparking), but i can assure to you that i have the same problem in a "clean" asterisk, 1.2 or 1.4. Tomorrow however i'll post the verbosedebug from an antoher installation. "Park with digits" means that the called person park the call pressing the dtmf sequence defined in features.conf (blindxfer => #1 or parkcall => ##). By: Francesco Romano (francesco_r) 2007-02-15 05:53:43.000-0600 I have uploaded a bt and verbose debug from a pure asterisk 1.4-r54290. By: Joshua C. Colp (jcolp) 2007-02-15 10:24:20.000-0600 Fixed in 1.2 as of revision 54622, 1.4 as of revision 54623, and trunk as of revision 54624.