Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!swrinde!ringer!djimenez From: djimenez@ringer.cs.utsa.edu (Daniel Jimenez) Newsgroups: comp.lang.c Subject: Re: Failure INSIDE malloc() ?? Message-ID: <1991Jun27.054457.16890@ringer.cs.utsa.edu> Date: 27 Jun 91 05:44:57 GMT References: Organization: University of Texas at San Antonio, San Antonio, Texas Lines: 29 In article phil@phd.UUCP (H Phil Duby) writes: >In article <677448705@macbeth.cs.duke.edu> lsn@duke.cs.duke.edu (Lars S. Nyland) writes: >> 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 zero, and is a valid memory >location. There are tools that detect (and repair) accesses >(especially modifications) to the low memory locations, but this does not >prevent a program from to use that memory. The offending I would add that free (p); p = NULL; doesn't do the trick, even if NULL is a completely invalid address, like all bits one. There could still be *other* pointers hanging around that are aliased to what p used to point to. This kind of thing has caused me endless headaches. q = p; ... free (p); p = NULL; ... q->info = 'A'; /* Argh! It'll take me weeks to find this bug! */ -- * Daniel A. Jimenez * Please excuse my longwindedness. * djimenez@ringer.cs.utsa.edu * This Sun terminal makes everything * dajim@lonestar.utsa.edu * I write seem important. * Opinions expressed here are mine only, and not those of UTSA.