[asterisk-bugs] [Asterisk 0015609]: WARNING[23025]: channel.c:952 __ast_queue_frame: Exceptionally long voice queue length queuing to Local

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Aug 5 12:53:16 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15609 
====================================================================== 
Reported By:                aragon
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15609
Category:                   Core/Channels
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 206273 
Request Review:              
====================================================================== 
Date Submitted:             2009-07-29 09:26 CDT
Last Modified:              2009-08-05 12:53 CDT
====================================================================== 
Summary:                    WARNING[23025]: channel.c:952 __ast_queue_frame:
Exceptionally long voice queue length queuing to Local
Description: 
Since upgrading to 1.4 SVN 206273 I see LOTS these errors when paging or
when calls are processed by app_queue.  When I see the messages during a
page I don't hear any paging (my Polycom phones continue to ring but no
paging audio).

I have no idea where the message is coming from how to reproduce, or
collect debug information for this specific issue.  I need help to find
root cause.
I think it could be caused by locking in autoservice since I see this lock
every time I see the warning message

=== Currently Held Locks ==============================================
=======================================================================
===
=== <file> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: 3057154960 (autoservice_run      started at [  238]
autoservice.c ast_autoservice_start())
=== ---> Waiting for Lock https://issues.asterisk.org/view.php?id=0
(autoservice.c): MUTEX 89 autoservice_run
&(&aslist)->lock 0x81798c8 (1)
=== --- ---> Locked Here: autoservice.c line 89 (autoservice_run)
=== -------------------------------------------------------------------


====================================================================== 

---------------------------------------------------------------------- 
 (0108671) mmichelson (administrator) - 2009-08-05 12:53
 https://issues.asterisk.org/view.php?id=15609#c108671 
---------------------------------------------------------------------- 
aragon: The text file you uploaded has a slightly different output for
"core show locks" than what you originally wrote in the description, so the
conditions may not be exactly the same as the last time you started seeing
this message. Specifically, the following lines are missing from the new
text file you uploaded:

=== ---> Waiting for Lock https://issues.asterisk.org/view.php?id=0
(autoservice.c): MUTEX 89 autoservice_run
&(&aslist)->lock 0x81798c8 (1)
=== --- ---> Locked Here: autoservice.c line 89 (autoservice_run)

This means that when you captured the output for the text file you
uploaded, there was no actual deadlock. I found the thread that was
printing all the "exceptionally long queue" messages, and it appears to be
a typical channel thread. Are you using /n on your local channels? 

cstadlmann: I would not expect for that patch you added to chan_local to
actually help in this situation. The reason is the DEADLOCK_AVOIDANCE macro
contains the same statements that were removed. The SMR comment alludes to
the fact that he's just replacing the in-lined code with the macro version.
The only thing that makes sense to me is that having DEBUG_THREADS enabled
in menuselect is somehow causing a slight timing variation which causes the
issue to be non-existent. Also, are you using /n on your local channels? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-05 12:53 mmichelson     Note Added: 0108671                          
======================================================================




More information about the asterisk-bugs mailing list