Summary:	ASTERISK-17739: possible deadlock in WaitExten()
Reporter:	Luke H (luckman212)	Labels:
Date Opened:	2011-04-21 19:49:46	Date Closed:	2011-08-29 12:56:41
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/PBX
Versions:	1.8.3	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When "WaitExten()" is called from inside the dialplan with no params, e.g. exten => 123,n,WaitExten(,) it ignores the default response timeout ($TIMEOUT(response)) and instead waits indefinitely. Dialplan will continue if user enters DTMF but otherwise dialplan execution is halted. see: http://www.freepbx.org/forum/freepbx/beta-program-issues/t-timeout-is-not-honored-by-ivr and also: http://pbxinaflash.com/forum/showthread.php?p=63863 ****** ADDITIONAL INFORMATION ****** For some reason this doesn't happen *all* the time, e.g. usually after a fresh boot or after shutting down & restarting Asterisk it will work for a while and then start hanging again.   Inserting a fixed numeric value into the WaitExten() e.g. WaitExten(3,) seems to fix the problem.  But this appears to be some kind of regression  as the old parameterless method used to work.  This could also be just syntax enforcement and FreePBX may have been writing bad dialplan code before so I am not sure who's bug it is.
Comments:	By: Paul Belanger (pabelanger) 2011-04-21 22:06:29 Debugging deadlocks: Please select DEBUG_THREADS and DONT_OPTIMIZE in the Compiler Flags section of menuselect. Recompile and install Asterisk (i.e. make install) This will then give you the console command: core show locks When the symptoms of the deadlock present themselves again, please provide output of the deadlock via: # asterisk -rx "core show locks" | tee /tmp/core-show-locks.txt # gdb -se "asterisk" <pid of asterisk> | tee /tmp/backtrace.txt gdb> bt gdb> bt full gdb> thread apply all bt Then attach the core-show-locks.txt and backtrace.txt files to this issue. Thanks! By: Luke H (luckman212) 2011-05-10 16:04:00 AFAIK this is basically a mis-use of the syntax by FreePBX, so as it's already been reported to the FreePBX project, and not really an Asterisk bug, this should probably just be closed out.