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

[David Lee]

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

(Updated Sept. 5, 2013, 4:39 p.m.)


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


Changes
-------

Addressed review comments:
 * Properly suspend/restore lock info during condition wait
 * Error if condition waiting on an unlocked mutex


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 (updated)
-----

  /branches/1.8/main/utils.c 398497 
  /branches/1.8/main/lock.c 398497 
  /branches/1.8/include/asterisk/lock.h 398497 

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/20130905/36473b65/attachment.htm>