From owner-freebsd-hackers Thu Sep 18 12:12:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28885 for hackers-outgoing; Thu, 18 Sep 1997 12:12:36 -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 MAA28880 for ; Thu, 18 Sep 1997 12:12:33 -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 NAA09103; Thu, 18 Sep 1997 13:12:21 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA13699; Thu, 18 Sep 1997 13:12:18 -0600 (MDT) Date: Thu, 18 Sep 1997 13:12:18 -0600 (MDT) Message-Id: <199709181912.NAA13699@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: Nate Williams , Graham Wheeler , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <10897.874608673@critter.freebsd.dk> References: <199709181811.MAA13376@rocky.mt.sri.com> <10897.874608673@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 [ Bugs in phk-malloc ] > Anyway, if you think so: do like so many others have done, look at the > source for phkmalloc.c and try to spot the error. I can't. I know, and I don't expect you to find any. But, it doesn't mean there isn't one. :) [ 'hangs' in malloc due to memory over-write causing circular lists ] > >> 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. > > No, all you have to do is to make each allocation have it's own set of > pages, munmap them when free is called and never use those pages again. > > You run out of address space really fast, and it is slow, but it works. It's slow, but how would it cause malloc to hang? > >> 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'. > > Not really, there is a simple way to find it I belive. Hack phkmalloc > the following way: Add a nontrivial checksum field to the freechunk > structure. Check before use, and update it after changes. Should > nail it in no time. Cool, sounds like another option *YOU* should implement. *grin* (just kidding, just kidding.....) Nate