From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Help me track down memory leakage
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 24 Nov 1992 04:58:23 GMT

abuhr@owlnet.rice.edu (Aaron M. Buhr) writes:

>      Thanks to all who responded to my earlier post about helping me
>track down the memory leak.  Most of the respondents said to either
>acquire a commercial product such as Purify, use one of the freely
>available routines, or make my own.  Since the Purify product is
>priced in the thousands of dollars it's out of my price range.  The
>only standard free memory allocation debugging product seemed to be
>the malloc_debug routines available on some Suns.  I decided to make
>my own routines, both so that I could customize it to fit my uses and
>because I thought I might be able to create my own faster than I could
>track down, learn, and integrate someone else's routine.

There is a package called dbmalloc which is free software, and comes
with source code and good documentation. I have found it to be very
easy to install and to use. I doubt that you would need to customize
it, but if you do, the source code is meticulously documented so it
shouldn't be too difficult. My only gripe is that it won't give you a
full stack trace (can't expect too much for $0 I guess :-), but it does
provide some hooks to work around that in particular cases.

Here's some extracts from the man page:

     DEBUG_MALLOC(3)	    UNIX System	V (VTI)	       DEBUG_MALLOC(3)

     NAME
	  dbmalloc - debugging malloc library

     [...]
     DESCRIPTION
	  This malloc library is a replacement for the standard
	  library to be	used during software development/debugging.
	  [...]
	  This library differs from the	standard malloc	library	in the
	  following ways:

	  1. Each malloc segment contains a magic number so that free
	  can verify that the pointer passed points to a valid malloc
	  segment.

	  2. Each malloc segment is filled with	a non-zero pattern so
	  that code that depends upon malloc segments being null will
	  fail.

	  3. The size of each segment will be at least 1 byte larger
	  than requested and the extra bytes will be filled with a
	  non-zero pattern.  When free is called, it will verify that
	  you did not go beyond	the number of bytes you	asked for.

	  4. When a segment is freed, it will be filled	with a
	  different non-zero pattern to	ensure that the	program
	  doesn't depend upon the use of already freed data.

	  5. Whenever any of the string	or memory functions (str*, b*,
	  mem*)	are called with	a pointer that is within the malloc
	  arena,  the operation	is checked to verify that it does not
	  overrun the malloced segment.	 A failure of this check is
	  considered a "warning	level error" (described	later) and is
	  handled accordingly.

	  6. Run time checking can include verification	of the malloc
	  chain	at each	and every call to one of the malloc functions
	  or manually by calling the malloc_chain_check	function.

	  7. Extensive support for tracking memory leaks is provided.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c