From owner-freebsd-hackers Thu Sep 18 11:12:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24447 for hackers-outgoing; Thu, 18 Sep 1997 11:12:00 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24442 for ; Thu, 18 Sep 1997 11:11:57 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id MAA08719; Thu, 18 Sep 1997 12:11:27 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA13376; Thu, 18 Sep 1997 12:11:25 -0600 (MDT) Date: Thu, 18 Sep 1997 12:11:25 -0600 (MDT) Message-Id: <199709181811.MAA13376@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: Graham Wheeler , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <10531.874599844@critter.freebsd.dk> References: <199709181606.SAA00506@cdsec.com> <10531.874599844@critter.freebsd.dk> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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