From owner-freebsd-hackers Thu Sep 18 12:42:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01020 for hackers-outgoing; Thu, 18 Sep 1997 12:42:58 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA01015 for ; Thu, 18 Sep 1997 12:42:54 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA11099; Thu, 18 Sep 1997 21:41:16 +0200 (CEST) To: Nate Williams cc: Graham Wheeler , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 13:12:18 MDT." <199709181912.NAA13699@rocky.mt.sri.com> Date: Thu, 18 Sep 1997 21:41:16 +0200 Message-ID: <11097.874611676@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181912.NAA13699@rocky.mt.sri.com>, Nate Williams writes: >[ '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? It wouldn't, it would detect accesses to free'ed memory. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."