Fix DEBUG_THREADS when lock is acquired in __constructor__
authorDavid M. Lee <dlee@digium.com>
Mon, 9 Sep 2013 20:13:40 +0000 (20:13 +0000)
committerDavid M. Lee <dlee@digium.com>
Mon, 9 Sep 2013 20:13:40 +0000 (20:13 +0000)
commitc2e6e1ef49d8e8745c9e4b6be2601b210a34506f
tree000084953c842ca083e688bcf8f36eed0cfd9747
parent0bcc676d09bbf11e02368ababe280795de61746d
Fix DEBUG_THREADS when lock is acquired in __constructor__

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).

(closes issue ASTERISK-22455)
Review: https://reviewboard.asterisk.org/r/2824/
........

Merged revisions 398648 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 398649 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 398651 from http://svn.asterisk.org/svn/asterisk/branches/12

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
include/asterisk/lock.h
main/lock.c
main/utils.c