The files malloc.c, free.c, realloc.c, and malloc.h have been edited,
and the new files write_trace.c and init_trace.c have been created,
to implement the tracing of calls to malloc, free, and realloc.

[WARNING: The implementation is system-dependent.  It works on our SunOS 3.2.]

The method is based on that described in the paper:

	"A Technique for Finding Storage Allocation Errors in
	 C-language Programs", David R. Barach, David H. Taenzer,
	 and Robert E. Wells; SIGPLAN Notices, V17#5 (May 1982).

All these changes and the associated new files are public domain,
and are not guaranteed.

Basically, the functions free and malloc are modified by inserting
calls to the new functions init_trace and write_trace.  Init_trace
is called the first time malloc is called; it opens the output file
named by the environment variable $MALLOCTRACE, or "malloc.out" by
default.  Each call to write_trace then writes to that trace file
a one-line description of the current event, e.g. "malloc of 256 at 5a10a".
It follows this by a traceback of the calling stack with one line for
each stack frame, e.g. "caller 0000210f", and an empty line.

The possible events are "malloc" and "realloc-to" to allocate memory,
"free" and "realloc" to free memory.  A call to realloc generates
both a "realloc" and a "realloc-to".

The variable _malstate provides interlocking so that when realloc
calls malloc or free, which it sometimes does, an additional tracing
line will not be generated, and so that no tracing will be generated
before initialization is complete or if the trace file cannot be opened.

The associated shell script "prleak", containing three awk programs, 
reads the $MALLOCTRACE or "malloc.out" (or other specified) file, and
does an "nm" on the program supposed to have generated it ("a.out"
by default).  It scans these outputs and produces a report of the
high water level of allocated data (excluding that from stdio, as far
as possible), the total amount of data remaining allocated at termin-
ation, and the tracebacks of all calls that left data allocated at
termination or that resulted in any error (including nonfatal ones
such as frees of unallocated data).  The tracebacks give entries in
forms such as "called from  5a9b [ _getframe + 42]", where 5a9b is in
hexadecimal and 42 in decimal.

						Mark Brader
						SoftQuad Inc.
						January 1987