Date: Thu, 18 Sep 1997 12:11:25 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Graham Wheeler <gram@cdsec.com>, hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709181811.MAA13376@rocky.mt.sri.com> In-Reply-To: <10531.874599844@critter.freebsd.dk> References: <199709181606.SAA00506@cdsec.com> <10531.874599844@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp writes: > In message <199709181606.SAA00506@cdsec.com>, Graham Wheeler writes: > > >i.e. the size is stored both immediately preceding and immediately > >following the useable space. As part of the consistency checking, > >these two sizes are compared and should match. This should catch almost > >all small overruns or underruns, and abort the process. So this > >malloc should be less tolerant of bugs in my code than pkhmalloc is, > >rather than more tolerant, > > again: depends. True, but I think Graham's arguement puts the ball in your court. Yes, it's *possible* that a bug in his code exists, but given that his other malloc has debugging capabilities built-in, one could argue that the burden of proof is now on PHK-malloc. .. > >Can you offer an explanation as to why the process never returns from > >the call to malloc, nor does it abort? This seems to indicate an infinite > >loop. Not having delved too deeply into your code, I can only speculate > >that the linked list is being made circular, so the process is in an > >infinite, looping traversal. Perhaps that is a check that can be added; > >namely that walking the list must always proceed forward, never backward > >(assuming that the list is kept in sequential order). > > This is about the only way you could get it to loop I think. That means > that somebody wrote to memory malloc hadn't passed them (ie: your code). Yikes, this would be 'Hard to Do', even by design (ie; self-modifying code). But, stranger things have happened, especially with dealing with malloc/free. I could understand that this could be a reason where phkmalloc would fail, and another debug library wouldn't. However, if you modified PHK-malloc's storage capability (say, have it allocate 2X normal memory), the problem should go away, since you'd be modifying something other than the 'prev/next' pointer variable. > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. This is a 'hard problem'. Graham, does your software run on a Solaris or HP/UX box? If so, you may consider getting an evaluation copy of Purify and running it against your code. IMHO, Purify is the *best* single-tool for pointing out these kinds of errors, aside from good programming practices. I find it even more useful than a debugger for 'hard to find' errors, although when coupled with a debugger it's usefulness is second to none. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709181811.MAA13376>