Merged revisions 78095 via svnmerge from
authorRussell Bryant <russell@russellbryant.com>
Fri, 3 Aug 2007 19:41:42 +0000 (19:41 +0000)
committerRussell Bryant <russell@russellbryant.com>
Fri, 3 Aug 2007 19:41:42 +0000 (19:41 +0000)
commitbefb383d1688f54fa269d027d6c91fe33bfb8133
treed62576c2d8d23f314e2eed13ce50e0e46ea0f827
parent661fa0b3744adcd8091952df48f9c975340e1004
Merged revisions 78095 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r78095 | russell | 2007-08-03 14:39:49 -0500 (Fri, 03 Aug 2007) | 28 lines

Add some improvements to lock debugging.  These changes take effect
with DEBUG_THREADS enabled and provide the following:

 * This will keep track of which locks are held by which thread as well as
   which lock a thread is waiting for in a thread-local data structure.  A
   reference to this structure is available on the stack in the dummy_start()
   function, which is the common entry point for all threads.  This information
   can be easily retrieved using gdb if you switch to the dummy_start() stack
   frame of any thread and print the contents of the lock_info variable.

 * All of the thread-local structures for keeping track of this lock information
   are also stored in a list so that the information can be dumped to the CLI
   using the "core show locks" CLI command.  This introduces a little bit of a
   performance hit as it requires additional underlying locking operations
   inside of every lock/unlock on an ast_mutex.  However, the benefits of
   having this information available at the CLI is huge, especially considering
   this is only done in DEBUG_THREADS mode.  It means that in most cases where
   we debug deadlocks, we no longer have to request access to the machine to
   analyze the contents of ast_mutex_t structures.  We can now just ask them
   to get the output of "core show locks", which gives us all of the information
   we needed in most cases.

I also had to make some additional changes to astmm.c to make this work when
both MALLOC_DEBUG and DEBUG_THREADS are enabled.  I disabled tracking of one
of the locks in astmm.c because it gets used inside the replacement memory
allocation routines, and the lock tracking code allocates memory.  This caused
infinite recursion.

........

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