https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87373 | russell | 2007-10-29 14:21:06 -0500 (Mon, 29 Oct 2007) | 5 lines
Remove a lock that doesn't make any sense. The regions lock needs to be held
when traversing the list of allocated chunks so that they can be printed out
to the CLI.
(Thanks to eliel on #asterisk-dev for pointing this out!)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@87392 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@78096 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r48987 | kpfleming | 2006-12-27 12:29:13 -0600 (Wed, 27 Dec 2006) | 2 lines
allow 'show memory' and 'show memory summary' to distinguish memory allocations that were done for caching purposes, so they don't look like memory leaks
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@48989 f38db490-d61c-443f-a65b-d21fe96a405b
- Create an astmm_log() macro that logs the same message to both stderr as well
as the mmlog file if it is open instead of duplicating the code everywhere.
- Use for loops for list traversals instead of while loops
- reduce nesting
- ensure locking isn't put around more than is necessary
- localize a struct definition
- change the limit of the path to the mmlog to PATH_MAX instead of 80
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@40780 f38db490-d61c-443f-a65b-d21fe96a405b
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@40722 f38db490-d61c-443f-a65b-d21fe96a405b
russell