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.