[asterisk-bugs] [Asterisk 0017407]: [patch] DEADLOCK_AVOIDANCE can actually generate dealocks

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17407 
====================================================================== 
Reported By:                pdf
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17407
Category:                   Core/General
Reproducibility:            sometimes
Severity:                   block
Priority:                   normal
Status:                     ready for testing
Target Version:             1.4.33
Asterisk Version:           1.4.31 
JIRA:                       SWP-1584 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-05-27 00:23 CDT
Last Modified:              2010-05-28 02:32 CDT
====================================================================== 
Summary:                    [patch] DEADLOCK_AVOIDANCE can actually generate
dealocks
Description: 
We have reported this issue to Digium support, however were asked to submit
the patch via this tracker.

In brief: the DEADLOCK_AVOIDANCE macro attempts to release an existing
lock, then relock after a usleep(1), to allow other code to proceed around
the lock.  However, it doesn't actually check to see if a lock was released
by the unlock, before taking a new lock.  This means that whenever there is
no lock released, a new lock is taken that will never be released, meaning
that DEADLOCK_AVOIDANCE actually leaks locks, which can obviously lead to a
deadlock.
====================================================================== 

---------------------------------------------------------------------- 
 (0122594) pdf (reporter) - 2010-05-28 02:32
 https://issues.asterisk.org/view.php?id=17407#c122594 
---------------------------------------------------------------------- 
Actually, thinking about it - logging in the macro, whilst still a good
idea to tell us that someone is doing something bad, will only be
marginally useful in tracking down the problem since this will only tell us
the point at which the macro was called without a lock, however the problem
code may be much further up the stack.

I've reported one possible instance of this in
https://issues.asterisk.org/view.php?id=17414, but I certainly
can't say that there aren't others... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-28 02:32 pdf            Note Added: 0122594                          
======================================================================