*BSD News Article 12660


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!not-for-mail
From: sef@Kithrup.COM (Sean Eric Fagan)
Newsgroups: comp.os.386bsd.bugs
Subject: Re: VM problems w/unlimited memory?
Date: 12 Mar 1993 13:01:06 -0800
Organization: Kithrup Enterprises, Ltd.
Lines: 33
Sender: sef@ftp.UU.NET
Message-ID: <1nqtmjINNlns@ftp.UU.NET>
References: <C3qpIH.Is9@unx.sas.com> <1nprd8$8nj@Germany.EU.net> <C3s2nz.9sz@unx.sas.com>
NNTP-Posting-Host: ftp.uu.net

In article <C3s2nz.9sz@unx.sas.com> sastdr@torpid.unx.sas.com (Thomas David Rivers) writes:
>
>  Well, just to make sure this wasn't an isolated case, some how
>related to my 8 meg of main memory and 30 meg swap; I tried the
>same procedure 
>  i.e.
>    [bash]$  csh
>    % unlimit
>    % sh

I asked a good friend and studly wizard to try this on his 4.4ish machine
(*not* a 386 running 386bsd).  He got a panic, a different one than
I did, though.

It seems that bash does something like

	dup2 (1, -2);

I don't know where this is; I may try to find it later today, when
I'm back at my console and can deal with a panic :).

Because the number of file descriptors is unlimited, the kernel treats
the -2 as 0xfffffffe, or whatever it is, and, strangely enough, is not
able to allocate that much memory!  (Or that many file descriptors, for
the 4.4ish system.)

So... that's the problem.  I'm thinking about the "right" way to fix it.
The fast&easy way to fix it would be to make an upper limit on the
number of file descriptors per process, that cannot be changed, and check
against that value in dup2() (in kern/kern_descrip.c).  That should
stop the panic.  I think.  Also, you can work around it by finding out
where in bash this dup2 is coming from, and changing it.