I've started hunting for memory leaks using a cool tool, dmemcheck,
that was written by a former Pingtel employee, Mike Mammarella. As
the documentation says
dmemcheck is [an LGPL] utility for Linux/x86 to help find memory leaks
in long-running server processes. It works by allowing memory
leaks to be found during specific periods of time during the
execution of the program, rather than the entire lifetime of the
program. For each memory leak, a full stack trace is provided, and
a graphical utility written in Java helps to sort and display the
leaks in a useful manner.
dmemcheck only intervenes when a program allocates or frees memory, so
it has much lower overhead than valgrind, and can be used on
production systems. It can be added on to a binary program when you
start it; it doesn't require compilation changes.
The best part is that dmemcheck only logs memory allocations for the
portions of the run that you specify, which removes from the memory
leak report most "false positives". The typical sequence of operation
is:
start the program
dmemcheck starts in idle mode, and does not record allocations
wait for program to initialize and reach steady state
send SIGUSR2 to the program, putting dmemcheck in recording mode
dmemcheck records allocations and frees
execute the operations suspected of leaking memory
send SIGUSR2 to the program, putting dmemcheck in draining mode
dmemcheck continues to notice frees but ignores further allocations
allow program to purge all transient state due to the operations
send SIGUSR2 to the program
dmemcheck outputs report of un-freed allocations and returns to idle
mode
I've used dmemcheck to find two memory leaks in sipxrls, and in both
cases its report was remarkably free of false positive leak reports.
To use dmemcheck:
- Go to http://dmemcheck.tigris.org
- From left nav column, select "Documents & files"
- Download rev. 1.2.2, which is released under LGPL.
- Unpack the tar file.
- Read ./README. Chuckle at the subtle jokes.
- Build with "make".
- Copy ./dmemcheck and ./dmemcheck.so into /usr/local/bin
- Build the analyzer with "make -C analyzer".
- Remember where analyzer/analyzer.jar is.
- Run the program with "dmemcheck [options] program [arguments].
- Use "kill -USR2 [pid]" to get a leak report from the proper segment of
execution.
- Use "java -jar analyzer.jar" to run the analyzer. Suck in the .mld
file produced during execution. It can display the data sorted and
grouped in several ways, some of which are more informative than others.
And remember:
Thus spake the master programmer:
``Though a program be but three lines long,
someday it will have to be maintained.''
Dale
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
