Path: utzoo!attcan!utgpu!watmath!att!pacbell!ames!ncar!gatech!ncsuvx!mcnc!rti!sas!walker
From: walker@sas.UUCP (Doug Walker)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Catching free memory violations
Keywords: FreeMem monitor debug memory spam
Message-ID: <1124@sas.UUCP>
Date: 2 Aug 89 14:47:39 GMT
References: <7408@ecsvax.UUCP>
Reply-To: walker@sas.UUCP (Doug Walker)
Organization: SAS Institute Inc, Cary NC
Lines: 33

In article <7408@ecsvax.UUCP> utoddl@ecsvax.UUCP (Todd M. Lewis) writes:
>
>I have a program which seems to use memory it doesn't own
>from time to time, and I'd like some way to catch it in the act.
>I've been thinking about a method to see if/when it messes up free
>memory, and I'd like to know why this wouldn't work:
I, too, have been interested in this problem, and I have a link library
of memory debugging routines that does the following:

* Trash all allocated memory before the application sees it
* Instead of actually freeing memory, put it on a chain until the machine
  runs out of memory.  Trash it.  Check it to make sure it stays trashed.
  (Don't trash with 0's, though - too often that's what the transgressor
   wants).
* Allocate a header and trailer before/after all allocations and set it
  to a known value.  Check the headers/trailers every so often; when
  they change, somebody trashed memory (usually a buffer overwrite).
* Detect the application not freeing memory upon exit
* Detect an invalid FreeMem or free() call
* Export this knowledge to an external process (MemWatch III) that could
  perform these checks for you asynchronously
* Any time an error occurs, give the filename and line number that 
  allocated the memory

Any other suggestions for features are welcome, including what to do if the
external process detects an error.  Right now I am putting up an alert like
MemWatch II did;  Andy Finkel requested that I put debugging info out the
serial port instead.

Right now I have the link library working and the external process working
with alerts.

--Doug