From owner-freebsd-hackers  Mon Oct 20 20:52:01 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA15010
          for hackers-outgoing; Mon, 20 Oct 1997 20:52:01 -0700 (PDT)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA14988
          for <hackers@freebsd.org>; Mon, 20 Oct 1997 20:51:54 -0700 (PDT)
          (envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id JAA02577;
	Tue, 21 Oct 1997 09:25:10 +0930 (CST)
Message-Id: <199710202355.JAA02577@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Graham Wheeler <gram@cdsec.com>
cc: hackers@freebsd.org
Subject: Re: Bug in 2.2.2 
In-reply-to: Your message of "Sat, 20 Oct 1997 18:48:12 +0200."
             <199710201648.SAA11704@cdsec.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 09:25:08 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > 
> > 	can you tell me how to reproduce it within X hours?
> > 	if i remember correctly, it was failing every X hours
> > 	for you.  if its statically linked i can hack on 
> > 	the shared library and see if i can track this down.
> 
> I wrote a small program to exercise the heap and ran it for about ten million
> iterations without a problem. Then I decided to add a periodic call to fork(),
> as both Midnight Commander and the firewall gateway program both do plenty 
> of these. When I ran this the O/S panicked almost immediately.

This is starting to sound as though it might be related to the problem 
that Marc Slemko and I (at least) are seeing with programs occupying 3x 
required swap.  I'm not sure if his system forks a lot, but our code 
certainly does.  No crashes/panics/arena corruption, but if there's 
collateral damage in the VM system, then I can imagine that phkmalloc 
is going to get its knickers much more twisted than other mallocs, 
because it seems to dovetail closely with the VM behaviour.

> Here is the program:

Saved.  I'm hoping to have a monster release-builder box going this 
morning, and if I do I'll try this on 2.2.5 and 3.x.

mike