Summary:	ASTERISK-05258: Forced Redirect via Manager API causes * to crash
Reporter:	j (j)	Labels:
Date Opened:	2005-10-06 16:39:59	Date Closed:	2011-06-07 14:00:48
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_output.txt.bz2 ( 1) backtrace.txt
Description:	Hey. * seems to crash when a call is forcefully redirected via the Manager API from a call queue. The problem doesn't happen every single time, but pretty close. I tried downloading the lastest CVS head (06-10-2005) to see if that would help, which is does not. Steps I took to reproduce the error: I have a SIP phone sitting in a call queue. I run a perl script that executes the Redirect function through the Manager API. The call gets redirected fine, the queue app seems to do what it's supposed to (stops MOH, displays a message about the user leaving), and everything seems to be cool. The call is routed to an auto attendant, which actually successfully sets variables, and changes the caller to different contexts based off certain conditions. The server crashes the first time it tries to play back a sound file, in my case Silence/1 . I ran a 'make valgrind' to try to get as much backtrace information as possible, but it seems to give the exact same input as a normal make in this case. I've included a backtrace in this report. If there's anything at all I can do to help, please let me know. Thanks j
Comments:	By: Clod Patry (junky) 2005-10-11 21:30:18 you said "changes the caller to different contexts based off certain conditions", which are these conditions exactly? Which Rev of file.c do you have? By: Matthew Nicholson (mnicholson) 2005-10-11 22:19:18 Can you attach the debug (and verbose) logs from asterisk as it is crashing?  From the time you send the redirect until asterisk crashes would be great.  The attached back trace tells us where asterisk is crashing but does not give us any ideas about what is causing it. By: Matthew Nicholson (mnicholson) 2005-10-11 23:51:33 I was unable to reproduce this issue.  We placed a sip call in a queue then used the manager interface to redirect the call to a context in the dialplan which proceeded to set a varible, execute playback, execute goto, execute background and wait exten, execute another playback, and hangup. We ran the test about 5 times with out any unusual behavior.  I would be intrested in logging into this system to debug this futher.  If you like you can send login information to matt located at matt-land [dot] com and mnicholson [at] digium dot com. By: j (j) 2005-10-12 09:18:01 Hey. I'm willing to share the dial plan with you guys if I can be assured confidentiality. My current employer is very concerned with keeping things secure. I have no problems sharing our set up via email or irc or something of that nature.  The revision of the file.c is ASTERISK_FILE_VERSION(__FILE__, "$Revision: 1.76 $")  It's from CVS HEAD from 2005-09-22. Note: I did try a more recent version with the same result when I posted the bug.  Ok, as for debug output: I tried making asterisk log verbose and debug messages to it's /var/log/asterisk/messages file, with no luck. I've never tried to do that before, so I'm obviously missing something :(  What I did do:  I got verbose and debugging output from the terminal and redirected all of it to a file. I hope that will do.  I completely understand the need for the logging, as I myself spent three or four fruitless hours trying to track this one down too :)  The output is from the initial execution of asterisk, all the way to the crash. There are no calls in the output except for the call that crashes. The manager script logs in, finds the channel, redirects it, and quits.  As for logging in to the machine, I'm afraid as I said before, my current employer is a little paranoid, and our current network set up makes it impossible for anyone, including myself, to log in from the outside. Adding even more frustration is the fact (and sore subject) that I don't have administration rights to our firewall (yet), so I can't even open some stuff up to let you in.  Perhaps I could walk you through setting up a test environment just like ours?  Let me know if there's anyting at all I can do. j By: BJ Weschke (bweschke) 2005-10-13 21:18:01 Yes. If you can provide us with more info to reproduce the environment and conditions, I'd be happy to try and reproduce it on lab equipment. By: j (j) 2005-10-14 12:36:09 Sure thing.  Send me an email at j@intuitivecreations.com to discuss further or send me your email and we can nail down some details.  Btw, was the debugging output any help? j By: Matthew Nicholson (mnicholson) 2005-10-14 17:37:45 Hmmm... nothing too unusual in that debug log.  Do all your backtraces look like the one you posted to us? By: j (j) 2005-10-17 08:23:40 Yep. Pretty much. bweschke has contacted me via email, so we'll see what we can do about replicating the environment and hopefully reproducing the error. j By: BJ Weschke (bweschke) 2005-10-17 10:16:13 GCC version this Asterisk was built with is < 3.00. gcc ver: gcc version 2.95.4 20011002 (Debian prerelease) I've asked him to go ahead and update his gcc (he's going to update his whole system) and rebuild with a gcc in spec and then we'll see if it can be reproduced. If it cannot be reproduced, we'll attribute this to a problem caused by a build made by an unsupported version of the compiler. By: BJ Weschke (bweschke) 2005-10-17 10:17:13 Closed for now. Reported will re-open if it happens again with a system that was built with a compiler that is in spec.