[asterisk-bugs] [Asterisk 0015911]: Deadlock in channel masquerade handling

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15911 
====================================================================== 
Reported By:                russell
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15911
Category:                   Core/Channels
Reproducibility:            have not tried
Severity:                   block
Priority:                   normal
Status:                     confirmed
Target Version:             1.6.3.0
Asterisk Version:           SVN 
JIRA:                       SWP-207 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 219302 
Request Review:              
====================================================================== 
Date Submitted:             2009-09-17 15:50 CDT
Last Modified:              2009-09-24 15:42 CDT
====================================================================== 
Summary:                    Deadlock in channel masquerade handling
Description: 
In Asterisk trunk and 1.6.2, ast_channels are stored in an astobj2
container, instead of a singly linked list as before.  The hash value is
based on the channel name.  So, during a masquerade, when the channel name
changes, the channel must be removed and reinserted into the hash table
using its new hash value.

This change introduced locking of the channels container where it did not
exist before.  Specifically, it introduces locking in the order of 1) the
ast_channel, and 2) the container.

Many other places in the code use the locking order 1) ast_channel
container, 2) channels, and this is the locking order that must be obeyed.

Some work needs to be put into masquerade handling to resolve this
deadlock and get it to follow the proper locking order.
====================================================================== 

---------------------------------------------------------------------- 
 (0111350) jpeeler (administrator) - 2009-09-24 15:42
 https://issues.asterisk.org/view.php?id=15911#c111350 
---------------------------------------------------------------------- 
Although the issue here is well understood I attached backtraces for the
deadlocked threads and core show locks for this scenario. It seems to be
easy to reproduce by using the bridge application. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-24 15:42 jpeeler        Note Added: 0111350                          
======================================================================