From owner-freebsd-hackers  Thu Sep 18 12:47:32 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA01351
          for hackers-outgoing; Thu, 18 Sep 1997 12:47:32 -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 MAA01343
          for <hackers@freebsd.org>; Thu, 18 Sep 1997 12:47:27 -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 NAA09322;
	Thu, 18 Sep 1997 13:46:48 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA13960; Thu, 18 Sep 1997 13:46:45 -0600 (MDT)
Date: Thu, 18 Sep 1997 13:46:45 -0600 (MDT)
Message-Id: <199709181946.NAA13960@rocky.mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Nate Williams <nate@mt.sri.com>, Graham Wheeler <gram@cdsec.com>,
        hackers@freebsd.org
Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) 
In-Reply-To: <11097.874611676@critter.freebsd.dk>
References: <199709181912.NAA13699@rocky.mt.sri.com>
	<11097.874611676@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

> 
> >[ '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.

Ahh, I misunderstand what you meant.  I thought that you meant that
getting PHK-malloc to spin was easy to do with the above, not that
detecting it would be easy to do.


Nate