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

[Asterisk Bug Tracker]

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-10 09:49 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)
=== -------------------------------------------------------------------


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

---------------------------------------------------------------------- 
 (0108846) mmichelson (administrator) - 2009-08-10 09:49
 https://issues.asterisk.org/view.php?id=15609#c108846 
---------------------------------------------------------------------- 
I don't think issue https://issues.asterisk.org/view.php?id=15594 is related,
but it's hard to tell. Not all of
the backtraces from those crashes are the same, so it's hard to pinpoint
the causes of those. Also, that issue is about crashes that are happening,
as opposed to periods of potential deadlock, so I think it is unrelated.

I tried running some tests, including cstadlmann's test of having two
queue members answer at the same time, but I could not make the warning
message appear. I also tried some pages, as were suggested by aragon, but
that did not work either.

My next plan is to try some other things, like placing transfers when
using Local channels, to see if that might trigger the condition. Also,
seeing as how cstadlmann's patch to chan_local appeared to fix his problem,
I'm also trying the same set of tests as before but with no special
compilation flags turned on, in case this is something which requires
precise timing.

Basically, I'm trying to think of ways that can cause a large queue of
audio frames to build up on a channel without the frames being read. Most
of the time, a channel is put into autoservice so that such a condition
cannot happen. One working theory I have is that since the calls are
daisy-chained across local channels, one end of the local channel may be
autoserviced correctly, but the other end is not, resulting in the large
queue of voice frames.

As for Ayth's problem with IAX2 channels, I have no idea what's going on
there. Sorry. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-10 09:49 mmichelson     Note Added: 0108846                          
======================================================================