Summary:	ASTERISK-20262: Asterisk console becomes unresponsive under heavy call load
Reporter:	Jeremy Pepper (jpepper)	Labels:
Date Opened:	2012-08-20 13:01:13	Date Closed:	2012-08-30 16:53:21
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	General
Versions:	11.0.0-beta1	Frequency of Occurrence	Occasional
Related Issues:
Environment:	Ubuntu 10.04.1 LTS	Attachments:
Description:	I've only managed to trigger this a couple times so far. Each time, I've held up 100 simultaneous SIP calls via the manager between a queue and another test server. It works for a while, but eventually I stop seeing verbose messages on the console, and when I run {{core show channels}} to confirm there are still calls up, the console hangs. The last time I triggered it, I had passed the {{-p}} option to Asterisk. I don't remember if I had the first time as well. There are still free CPU cycles to be had, though—Apache and SSH remained responsive on the same box. I have triggered this issue with both {{-r}} and {{-c}}.
Comments:	By: Richard Mudgett (rmudgett) 2012-08-20 14:46:04.799-0500 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: Jeremy Pepper (jpepper) 2012-08-30 15:49:04.325-0500 Terribly sorry about the delayed response! This turned out to be caused by a patch we had applied and not a problem I could reproduce on completely stock Asterisk. Sorry for jumping the gun reporting this! By: Matt Jordan (mjordan) 2012-08-30 16:53:21.839-0500 No problem - thanks for letting us know!