Re: zmailer - memory leaks

[Mark Moraes <Mark-Moraes@deshaw.com>]

[warning, advertising and biased opinions ahead:-]

 | Get Hans Boehm's garbage collecting malloc.  It has an option to report
 | leaks (rather than simply silently collecting them).  gc_malloc is
 | free, ftp from parcftp.xerox.com.

Purify is invaluable for finding memory corruption bugs that almost no
other tool will find (there's a few that CodeCenter catches and purify
doesn't, but CodeCenter is slower and clunkier).  In free software, I
haven't yet seen a tool that's more paranoid about detecting memory
corruption than my malloc.

For leaks, again, Purify is the best I know of.  I don't know of anything
that comes even close.  gc_malloc can be fooled in many ways -- it's
conservative failure mode is essential for the allocation/free function,
but is not what you want for leak detection.  It also falls down if the
program being checked has its own layers on top of malloc/free, as
Zmailer does.  (I haven't looked at gc_malloc since 1988, it may well
have improved since then)

You can also use my malloc for detecting leaks -- if you compile with
malloc.h, and MALLOC_TRACE defined, you get some stack backtracing, but
to fully exploit it in Zmailer, you'd need to write a few wrappers of the
sort found in _malloc.c; they're trivial.  I believe that my malloc is
superior to Marcus Ranum's memory leak locator/profiler
(comp.sources.misc, v16i019) and Michael Schwartz's Malloc leak trace
package (comp.sources.misc, 1987, don't have the vol and issue) but
inferior to Mark Brader et al's "Malloc package with tracing"
(comp.sources.unix, v18i066) -- the latter grubs through the stack in a
non-portable way, but thus produces stack traces without the #define
kludges that Marcus, Michael and I use.

	Mark, malloc maniac...