[asterisk-bugs] [Asterisk 0015609]: [patch] 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:                   crash
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
JIRA:                        
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-09-25 08:15 CDT
====================================================================== 
Summary:                    [patch] 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)
=== -------------------------------------------------------------------


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015109 [patch] Abort by memory allocator, poss...
has duplicate       0015900 Console flood &amp; CPU load 100% when ...
related to          0015817 crash in local_attended_transfer, likel...
related to          0015845 Crash during attended transfer occurs
====================================================================== 

---------------------------------------------------------------------- 
 (0111368) aragon (reporter) - 2009-09-25 08:15
 https://issues.asterisk.org/view.php?id=15609#c111368 
---------------------------------------------------------------------- 
In my previous note I mentioned the circumstances of the lock.
Then I remembered something I saw in one of the latest committed
revisions.
Reviewboard r362 committed in revision 219136.
I am currently testing SVN-branch-1.4-r219816M and I still see the
warnings and locks.

This quote from the review board made me think of the original issue
posted in my bug report about the WARNINGS and locks.  It maybe irrelevant
but I wouldn't know since I have no programming skills.

Russell Bryant
Posted 1 week ago (September 17th, 2009, 9:24 a.m.)

I have one last comment, but it's really about code that was already
there.  It seems like we hold the channel list locked a whole lot longer
than we need to when freeing a channel.  However, I guess we should just
leave it alone, since in the majority of cases, the channel list isn't
going to be touched in ast_channel_free() anymore, since you have it in
ast_hangup().  Ship it!

/tags/1.6.1.1/main/channel.c (Diff revision 4)
	

	1399 	

	if (inlist)

1393 	

	AST_RWLIST_UNLOCK(&channels);

	1400 	

		AST_RWLIST_UNLOCK(&channels);

    Can you think of any reason we wait this long to unlock the channel
list?

       1.

          Matthew Nicholson 1 week ago (September 17th, 2009, 9:29 a.m.)

              I noticed this as well.  I have no idea why the code is like
this.  We should be able to unlock the list once we remove our channel from
it without any problems.  Thanks for the feedback. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-25 08:15 aragon         Note Added: 0111368                          
======================================================================