Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!atha!aunro!alberta!cpsc.ucalgary.ca!yogi.hsc.ucalgary.ca!janus.mtroyal.ab.ca!phd!phil
From: phil@phd.UUCP (H Phil Duby)
Newsgroups: comp.lang.c
Subject: Re: Failure INSIDE malloc() ??
Message-ID: <phil.7974@phd.UUCP>
Date: 25 Jun 91 16:59:47 GMT
Followup-To: comp.lang.c
Organization: Priviate Amiga Site
Lines: 27

In article <677448705@macbeth.cs.duke.edu> lsn@duke.cs.duke.edu (Lars S. Nyland) writes:
> I have found over the years that failures that appear to
> be inside of malloc() usually have to do with corrupt data
> structures.  How do they get corrupted?  Not by malloc, not
> usually anyway.
>
> Usually, like many other bugs in C, some pointer has gone
> astray, and you have used it, assigned values to its location,
> and ruined malloc's data structures.
>
> I would bet that you still use a pointer after you have freed
> the memory it points to.  You might amend your free statements
> to be more like:
>       free(p); p = NULL;
> just to make sure that you don't use the pointers after you have
> freed them.
Setting a pointer to NULL does not (at least on some systems) prevent it
from being used.  On my AMIGA, NULL <IS> zero, and is a valid memory
location. There are <run time> tools that detect (and repair) accesses
(especially modifications) to the low memory locations, but this does not
prevent a program from <attempting> to use that memory.  The offending
program is not normally affected, and is usually not even known, except
from the context of what programs are concurrently running.

H. Phil Duby                     uunet!keyword!calgary!ajfcal!mtroyal!phd!phil
(AMiga Users of Calgary)         AMUCexpress BBS - 650 meg PD Software
Fido net node 1:134/27     (403) 282-5137/5171/5224/5238 3/12/24/24 MNP bps