Tracking memory leaks..

[Andrew Duane]

In article <3950011 at eecs.nwu.edu>, naim at eecs.nwu.edu (Naim Abdullah) writes:
> I want to check sections of a big program for memory leaks. My basic
> strategy was to define functions xmalloc() and xfree() that would keep
> track of the amount allocated, and to see if the amount went down to
> zero where it should (I wanted to use "#define malloc xmalloc" in the
> main header file to replace occurrences of malloc() and free()).

In order to find memory leaks here, I wrote some routines to
put into your program to track and report bad mallocs, bad
frees, mallocs without frees, etc.

The architecture of them is a new set of malloc/realloc/free
routines that get spliced into your C library (using ar). The
new routines generate entries into an audit file and then call
the "real" routines (which are renamed). There are new calls
added to start the audit file wherever you want, and to turn
loggin on and off at will. Then, there is a separate program
called NMPP (namelist postprocessor) which sifts through the
audit file and generates a stack trace of the program at each
point a malloc/free routine was called. It can weed out
"properly matching" pairs, and just report the problems, or it
can report all calls.

The routines and programs run on a Sun-3, using SunOS 3.x.
I don't know if they will run elsewhere (there is a little
assembler "magic" to get the stack trace, and it relies on the
format of the Sun stack frame).


Andrew L. Duane (JOT-7)  w:(508)-658-5600 X5993  h:(603)-434-7934
Compugraphic Corp.			 decvax!cg-atla!duane
200 Ballardvale St.		       ulowell/ \laidback
Wilmington, Mass. 01887		   cbosgd!ima/   \cgeuro
Mail Stop 200II-3-5S		     ism780c/     \wizvax

Only my cat shares my opinions, and she's breaking in the new help.