[asterisk-bugs] [Asterisk 0017407]: [patch] DEADLOCK_AVOIDANCE can actually generate dealocks
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu May 27 18:40:21 CDT 2010
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-27 18:40 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.
======================================================================
----------------------------------------------------------------------
(0122589) pdf (reporter) - 2010-05-27 18:40
https://issues.asterisk.org/view.php?id=17407#c122589
----------------------------------------------------------------------
Adding some logging is certainly a good idea, and will help find coding
errors, but leaving the existing code in place means that any time someone
calls DEADLOCK_AVOIDANCE outside a lock, they'll leak a lock and will get
stuck on it later. Surely it's better to (perhaps log first as you say)
continue if called unnecessarily, rather than potentially bring the whole
box to a halt by adding a lock that will never be released?
Issue History
Date Modified Username Field Change
======================================================================
2010-05-27 18:40 pdf Note Added: 0122589
======================================================================
More information about the asterisk-bugs
mailing list