From owner-freebsd-questions  Wed Apr  9 21:23:54 1997
Return-Path: <owner-questions>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id VAA12897
          for questions-outgoing; Wed, 9 Apr 1997 21:23:54 -0700 (PDT)
Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA12886
          for <questions@FreeBSD.ORG>; Wed, 9 Apr 1997 21:23:51 -0700 (PDT)
Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id VAA05216; Wed, 9 Apr 1997 21:23:44 -0700 (PDT)
Date: Wed, 9 Apr 1997 21:23:44 -0700 (PDT)
From: Doug White <dwhite@gdi.uoregon.edu>
X-Sender: dwhite@localhost
Reply-To: Doug White <dwhite@resnet.uoregon.edu>
To: Eric Yagerlener <eyager@novagate.com>
cc: questions@FreeBSD.ORG
Subject: Re: vm_fault bug in 2.1.0?
In-Reply-To: <Pine.BSF.3.91.970408104952.199A-100000@localhost>
Message-ID: <Pine.BSF.3.96.970409212156.4997j-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-questions@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, 8 Apr 1997, Eric Yagerlener wrote:

> I have 32M of ram and and 27M of swap.  The error is easily reproducable.
> 
> I logged in as root and did the following command on a directory that 
> contained 35 files that were 11.6M long total and were compressed with 
> 'compress'.
> 
> zcat * |less
> 
> Things work well and I'm able to scroll through the files.  I decide to go
> searching for keywords through all these files using less's search
> command.  It works fine at first, but as you get closer to the end of the
> files, things get gradually slower and slower.  Finally it reaches the
> point to where the system will suddenly do nothing but disk swapping, and
> all other processes are completely dead in the water and eventually die
> because of the lack of memory.  However, less won't die and keeps on
> thrashing away despite all the vm_faults it's generating.  My guess is
> that less is spawning a child process that will thrash the system until a
> vm_fault occurs kills that child process, less will simply ignore it and
> create another one that does the exact same thing an infinite amount of 
> times.

It sounds more like a memory hole in less (trying to store the output of
the zcat) than a VM system fault.  Considering this is 2.1.0, I doubt we
can do anything for you.  If you can get a new system running 2.2.1 or
newer to do it, then we might listen.

> Apr  8 10:22:47 wolfden /kernel: Process 656 killed by vm_fault -- out of swap
> 
> Is this the vm_fault bug that I heard mention of?

No, that's the vm_fault function (trying to) save your bacon by killing
processes.

Doug White                              | University of Oregon  
Internet:  dwhite@resnet.uoregon.edu    | Residence Networking Assistant
http://gladstone.uoregon.edu/~dwhite    | Computer Science Major