Comments: Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From: "George Foot" <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: sparhawk AT eunet DOT at (Gerhard Gruber)
Date: Thu, 27 Aug 1998 16:11:44 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: memory leaks
Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk
CC: djgpp AT delorie DOT com
Message-Id: <E0zC3jf-00048h-00@sable.ox.ac.uk>
Precedence: bulk

On 27 Aug 98 at 7:38, Gerhard Gruber wrote:

> Destination: "Cephaler" <cephaler AT hotmail DOT com>
> From: Gruber Gerhard
> Group: comp.os.msdos.djgpp
> Date: 26 Aug 1998 21:42:48 GMT:
> 
> >  I've just finished a good sized chunk of code for my game, and it uses
> >lots and lots of pointers. I know from past experiences that memory leaks
> >make programs crash (over time?) But this one seems to be ok.. I figure
> >since it's a memory 'leak' (I don't really know what a leak is, a pointer
> >that's wasn't freed?) I'd go check mem(the dos command) to see if any of
> >the values changed, but I began to wonder if windows hides some values from
> >command.com.. Is there a quick way to see if you've got a memory leak? 
> 
> When I suspect something of this, I usually replace all call to malloc() with
> a macro MALLOC and define this macro to write to a logfile. Same for free() of
> course. Then you can wordcount the number of times you called malloc and free.
> If they are the same it's usually ok unless you didn't use realloc (I usually
> don't). Of course you don't need to write to a file you can also use a static
> variable where you count each malloc/free and check it with a debugger or a
> printf on exit or something. If there is a better way, I'd glad to hear about
> it, though. :)

I made some utilities to do something like this; you can download
http://users.ox.ac.uk/~mert0407/downloads/findleak.zip if you like. 
It basically works as above, logging calls to malloc, realloc,
strdup and free, along with the pointer produced by malloc or
strdup, passed to free, and both the passed and produced pointers
for realloc.  Then there's a utility which you run on the log file, 
that matches up the calls, based upon the addresses in the logs, and 
notifies you if you ever do anything wrong (forget to free allocated 
memory, free a block twice, free an invalid pointer, etc).  It tells 
you what source file and line number caused the bad operation.

I wrote this before I knew about other tools like MSS and Fortify.  
They're probably much better tools for this job (but bigger too).

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk