Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!stolaf!mmm!umn-cs!herndon
From: herndon@umn-cs.UUCP
Newsgroups: net.lang.c
Subject: Re: oops, corrupted memory again!
Message-ID: <1700012@umn-cs.UUCP>
Date: Tue, 29-Apr-86 17:05:00 EDT
Article-I.D.: umn-cs.1700012
Posted: Tue Apr 29 17:05:00 1986
Date-Received: Fri, 2-May-86 08:39:41 EDT
References: <4495@cbrma.UUCP>
Lines: 17
Nf-ID: #R:cbrma:-449500:umn-cs:1700012:000:614
Nf-From: umn-cs!herndon    Apr 29 16:05:00 1986



  You didn't post your address!  A (partial) solution to the
problem of not freeing/allocated memory was published in
SIGPLAN Notices a few years back.  Look in the May 1982 issue
for "A Technique for Finding Storage Allocation Errors in
C-language Programs", by David R. Barach, David H. Taenzer,
and Robert E. Wells.
  The technique used in the article is fairly simple, and is
more oriented towards finding allocation errors.  Depending
on the severity of your errors, their technique might be
applicable.

				Robert Herndon
				...!ihnp4!umn-cs!herndon
				herndon@umn-cs
				herndon.umn-cs@csnet-relay.ARPA