[asterisk-dev] [Code Review] 2824: Fix DEBUG_THREADS when lock is acquired in __constructor__

David Lee reviewboard at asterisk.org
Wed Sep 4 17:14:41 CDT 2013


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2824/
-----------------------------------------------------------

Review request for Asterisk Developers, Matt Jordan and Mark Michelson.


Bugs: ASTERISK-22455
    https://issues.asterisk.org/jira/browse/ASTERISK-22455


Repository: Asterisk


Description
-------

This patch fixes some long-standing bugs in debug threads that were
exacerbated with recent Optional API work in Asterisk 12.

With debug threads enabled, on some systems, there's a lock ordering
problem between our mutex and glibc's mutex protecting its module list
(Ubuntu Lucid, glibc 2.11.1 in this instance). In one thread, the module
list will be locked before acquiring our mutex. In another thread, our
mutex will be locked before locking the module list (which happens in
the depths of calling backtrace()).

This patch fixes this issue by moving backtrace() calls outside of
critical sections that have the mutex acquired. The bigger change was to
reentrancy tracking for ast_cond_{timed,}wait, which wrongly assumed
that waiting on the mutex was equivalent to a single unlock (it actually
suspends all recursive locks on the mutex).


Diffs
-----

  /branches/1.8/main/lock.c 398291 

Diff: https://reviewboard.asterisk.org/r/2824/diff/


Testing
-------

Asterisk 12, DEBUG_THREADS+OPTIONAL_API on Ubuntu Lucid starts without
deadlock.

Asterisk 1.8, DEBUG_THREADS runs fine.


Thanks,

David Lee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130904/3248f031/attachment.htm>


More information about the asterisk-dev mailing list