[asterisk-bugs] [Asterisk 0012307]: Deadlock in chan_local

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12307 
====================================================================== 
Reported By:                callguy
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12307
Category:                   Channels/chan_local
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 105409 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-26-2008 10:46 CDT
Last Modified:              03-27-2008 13:21 CDT
====================================================================== 
Summary:                    Deadlock in chan_local
Description: 
We are seeing in certain situations (mainly a SIP hairpin that redirects a
call on the same server out to another user via the local channel) a
deadlock will occur. Once the deadlock occurs the system will continue to
process calls for a period of time, but will eventually hang completely. 

Console output, core show locks, and output of ast_grab core attached. 
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 03-27-08 13:21  
---------------------------------------------------------------------- 
I found the code path that causes this deadlock.

Here's the stack which leads to the problem:

__ast_read -> ast_read_generator_actions -> moh_files_generator ->
ast_write -> local_write -> local_queue_frame

What was confusing before was that there actually is deadlock avoidance
built into the local_queue_frame function. local_queue_frame is called with
the assumption that the channel passed in is locked. local_queue_frame has
to lock a second channel too, and if it fails to lock it, then it unlocks
the alreday locked channel (as well as the local_pvt structure) to allow
whatever thread is currently using the channel we're attempting to lock to
finish with it. The problem here is that by following the code path shown
above, the initial channel passed into local_queue_frame is locked TWICE
beforehand. This means that releasing the lock on that channel does nothing
since it was recursively locked.

Now that the problem has been identified, I'll work on finding a solution. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-27-08 13:21  putnopvut      Note Added: 0084663                          
======================================================================