Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!uunet!zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!proxima!undeed!ucthpx!uctcs!gram From: gram@uctcs.cs.uct.ac.za (Graham Wheeler) Newsgroups: comp.lang.c Subject: Re: Does TC's farrealloc have a bug? Message-ID: Date: 24 Jun 91 08:00:34 GMT References: <1991Jun19.083945.8921@ucthpx.uct.ac.za> <6574@ns-mx.uiowa.edu> Sender: news@ucthpx.uct.ac.za (UCT News Admin.) Organization: University of Cape Town Lines: 35 In <6574@ns-mx.uiowa.edu> colburn@tessa (alex colburn) writes: >In article <1991Jun19.083945.8921@ucthpx.uct.ac.za> gram@uctcs.uucp (Graham Wheeler) writes: >>I am reposting this article as I never saw the original appear when using nn >>records, of average size about 6 bytes. Whenever the size changes, I use >>farrealloc. I have over 300kb available at the time I start allocating these >>nodes. I also keep track of the number of allocated bytes. My problem is that >>I get a memory allocation failure at about 120kb of allocated memory. This > I don't think your problem lies in Borland's internal memory >management systems, it would kind of silly for them to write something >that uses twice as much memory as it is managing. Is this error message >something you get, and then its time for a reboot? If so, I bet you're >referencing invalid addresses. No, I print the error message when farrealloc returns NULL, and I do a clean exit. > How are you keeping track of your reallocated memory? If you have >some sort of linked list data structure, when you farrealloc you just might >be scrambling pointers. For debugging purposes try doing a farheapcheck() I actually have a tree structure (in fact, a graph) but instead of using pointers I use indexes into an array of pointers. This means I don't have to go patch all references to a node whose address might get changed by realloc. The problem is not a bug in the structure (it works fine); just that I am running out of memory too soon. And from the responses I have seen, this seems to be due to the 16-byte granularity of allocations, bearing in mind my average allocation is for six bytes. -- Graham Wheeler | "That which is weak conquers the strong, Data Network Architectures Lab | that which is soft conquers the hard. Dept. of Computer Science | All men know this; none practise it" University of Cape Town | Lao Tzu - Tao Te Ching Ch.78