Summary:	ASTERISK-19156: 1.8 SVN: channel.c:1474 __ast_queue_frame: Exceptionally long voice queue length queuing to Local during paging
Reporter:	David Brillert (aragon)	Labels:
Date Opened:	2012-01-02 12:28:42.000-0600	Date Closed:	2012-09-17 12:42:40
Priority:	Minor	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_local
Versions:	SVN	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) cli_and_core_show_locks.txt ( 1) gdb_tread_apply_all_pid.txt ( 2) malloc_debug.txt ( 3) paging_valgrind_ast_CLI.txt ( 4) valgrind.txt
Description:	During a normal page and with debug options dont optimize and debug threads I get an unusable system when trying to page. I can reproduce on every paging attempt. I have to mark as a regression because I used to be able to run Asterisk in production with debug options in order to capture gdb files after an unexpected segfault. Now I cannot run debug options at all on effected systems.
Comments:	By: David Brillert (aragon) 2012-01-02 12:30:13.253-0600 Core show locks and CLI output during page attached. By: David Brillert (aragon) 2012-01-02 12:30:58.839-0600 gdb thread debug attachment during warning messages. By: David Brillert (aragon) 2012-01-02 12:32:17.424-0600 System is unusable during paging due to huge delays in signalling and RTP. By: David Brillert (aragon) 2012-01-02 12:57:26.207-0600 Revision: 349445 By: Stefan Schmidt (schmidts) 2012-01-03 05:10:41.139-0600 i had the same problem with debug symbols. The whole system is not locked but blocked and slow. Normally debug threads is only necessary for special situations. DONT OPTIMIZE should be enough to get a good GDB output. And your system should run fine only with dont optimize enabled. By: David Brillert (aragon) 2012-01-09 08:40:59.929-0600 I tried to run Asterisk in Valgrind with debug options enabled and I could not get any SIP peers to stay registered due to delays. So I tested a non debug version of Asterisk and was able to run Asterisk in Valgrind long enough to capture some Valgrind and * CLI output which I have now attached. By: Matt Jordan (mjordan) 2012-01-23 16:30:44.274-0600 So, regardless of how the debug options worked in the past, they are compile time debugging options that will impact system performance.  As Asterisk changes, sometimes how threads interact also changes - and that means that some of these options, which previously did not have a large impact on performance, now force your system to a crawl.  If there are ways to change these debugging options such that they interfere with the system less but still perform their core functionality then that's fine - but without pin-pointing what the limitation is, its going to be hard to call this a 'bug'. Also, as Stefan said, you should only need DONT_OPTIMIZE turned on to get a valid backtrace.  While that will impact system performance some, it (usually) is not nearly as intrusive as DEBUG_THREADS - which is really needed for deadlock detection/debugging. By: David Brillert (aragon) 2012-01-25 08:12:10.388-0600 Thanks Matt. I have been running production versions of Asterisk 1.8 without those debug options to avoid performance issues.  Segfaults have been pretty rare while deadlocks are more frequent.  I would like to run with backtrace and thread debugging options in production since that makes it very quick to create tickets with the relevant traces to get the issues fixed much quicker.  I don't like to see my customers suffer or get angry when their systems do not perform as they expect so hopefully this problem can get sorted out without much difficulty.  Paging seems to be the one area which affects performance the most when running with these debug options enabled. By: David Brillert (aragon) 2012-09-17 12:42:00.462-0500 I do miss the old 1.4 days when I could run with DEBUG_THREADS enabled on each install to make core show locks easier to get. This ticket is too old for me now. Closing it out.