Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!elroy.jpl.nasa.gov!swrinde!mips!pacbell.com!ucsd!sdcc6!beowulf!lindwall
From: lindwall@beowulf.ucsd.edu (John Lindwall)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Kill and Getting Killed, heh.
Message-ID: <19717@sdcc6.ucsd.edu>
Date: 24 May 91 17:02:24 GMT
References: <1991May17.193234.24598@wehi.dn.mu.oz> <1237@cbmger.UUCP> <1991May24.203418.24601@wehi.dn.mu.oz>
Sender: news@sdcc6.ucsd.edu
Organization: CSE Dept., UC San Diego
Lines: 23

In article <1991May24.203418.24601@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes:
>Something must have got lost in the translation! _I_ know it is not the 
>fault of SDB. I know that _MY_ code is loosing the memory. But why? Where?
>Since SDB actually steps line by line, it could maintain a list of
>memory allocated and let me know what I didn't return, which would be a lovely
>programming tool and one I need just at the moment (and judging by the "I'm
>loosing my memory posts", others need fairly regularly). 

Take a look at Amiga World Tech Journal Vol 1, No 2.  There is an article
by Doug Walker called "Debugging Memory Errors".  It describes the most
common memory allocation errors and techniques for avoiding them.  It also
includes a library of routines which replace AllocMem/malloc/Free/free/etc..
with routines that perform sanity checks on your calls.  The library is
on the disk (I hate paying for the disk!  Whay not a BBS?).  This library
sounds perfect for you -- it is supposed to report line numbers in YOUR
SOURCE CODE for an offending memory allocation/deallocation call!  Note:
I haven't used the library yet, but since its written by Doug Walker I'm
sure its excellent.

John
-- 
John Lindwall			lindwall@cs.ucsd.edu
"Oh look at me! I'm all flooby! I'll be a son of a gun!" -- Flaming Carrot