Review Board 1.7.16

Fix DEBUG_THREADS when lock is acquired in __constructor__

Review Request #2824 - Created Sept. 4, 2013 and submitted

David Lee
mjordan, mmichelson
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).
Asterisk 12, DEBUG_THREADS+OPTIONAL_API on Ubuntu Lucid starts without

Asterisk 1.8, DEBUG_THREADS runs fine.
Review request changed
Updated (Sept. 10, 2013, 8:18 a.m.)
  • changed from pending to submitted
Committed in revision 398742 runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to