Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!sgiblab!darwin.sura.net!udel!sbcs.sunysb.edu!sbcs!stark From: stark@cs.sunysb.edu (Gene Stark) Subject: Bug in Rlimit initialization? (was Re: getdtablesize) Message-ID: <STARK.92Oct1143116@sbstark.cs.sunysb.edu> Sender: usenet@sbcs.sunysb.edu (Usenet poster) Nntp-Posting-Host: sbstark Organization: SUNY at Stony Brook Computer Science Dept. References: <tlukka.717504312@vipunen.hut.fi> <Bv7Dz7.C2o@BitBlocks.com> <1992Sep29.142535.21001@nntp.hut.fi> <1992Sep30.164745.13200@fcom.cc.utah.edu> Date: Thu, 1 Oct 1992 19:31:16 GMT Lines: 65 >In article <1992Sep29.142535.21001@nntp.hut.fi> alo@kampi.hut.fi (Antti Louko) writes: >>>In article <Bv7Dz7.C2o@BitBlocks.com> bvs@BitBlocks.com (Bakul Shah) writes: >>>tlukka@vipunen.hut.fi (Tuomas Lukka) writes: >>>>for(i=getdtablesize(); --i>2; close(i)); >>>>and getdtablesize returned something like 2000000000 and this >>>>naturally would take a while to run... >> >>>Another culprit is popen(). It attempts to allocate an array to hold >>>getdtablesize() number of descriptors and fails under zsh. >> >>>Now I don't think what zsh is doing is wrong. The problem is in >>>the use of getdtablesize() in popen() and the code above. What is >>>needed is a system call that returns the highest *open* file >>>descriptor number. Funny, I noticed this just tonight and tracked it down. I noticed that after issuing the "unlimit" command to the shell (not running as superuser), the "mtools" commands failed to work. I traced the problem to a call to "getdtablesize" to obtain the size of the open file table, followed by a call to "malloc" to allocate corresponding storage. The problem was that the "unlimit" command was setting the RLIMIT_OFILE component of the per-process resource limits to RLIM_INFINITY. The behavior of "getdtablesize" is simply to return this value (0x7fffffff), and it is of course ridiculous to attempt to allocate this much memory. I question whether "setrlimit" should be setting the RLIMIT_OFILE and RLIMIT_NPROC values to RLIM_INFINITY, rather than NOFILE and MAXUPRC, respectively. The following patch shown below to /sys/kern/init_main.c should fix this. I would appreciate comments on whether this is a reasonable thing to do. - Gene Stark *** /sys/kern/init_main.c.orig Sat Jul 11 20:32:04 1992 --- /sys/kern/init_main.c Wed Sep 30 22:30:48 1992 *************** *** 161,172 **** */ p->p_limit = &limit0; for (i = 0; i < sizeof(p->p_rlimit)/sizeof(p->p_rlimit[0]); i++) limit0.pl_rlimit[i].rlim_cur = limit0.pl_rlimit[i].rlim_max = RLIM_INFINITY; ! limit0.pl_rlimit[RLIMIT_OFILE].rlim_cur = NOFILE; ! limit0.pl_rlimit[RLIMIT_NPROC].rlim_cur = MAXUPRC; limit0.p_refcnt = 1; /* * Allocate a prototype map so we have something to fork */ --- 161,174 ---- */ p->p_limit = &limit0; for (i = 0; i < sizeof(p->p_rlimit)/sizeof(p->p_rlimit[0]); i++) limit0.pl_rlimit[i].rlim_cur = limit0.pl_rlimit[i].rlim_max = RLIM_INFINITY; ! limit0.pl_rlimit[RLIMIT_OFILE].rlim_cur = ! limit0.pl_rlimit[RLIMIT_OFILE].rlim_max = NOFILE; ! limit0.pl_rlimit[RLIMIT_NPROC].rlim_cur = ! limit0.pl_rlimit[RLIMIT_NPROC].rlim_max = MAXUPRC; limit0.p_refcnt = 1; /* * Allocate a prototype map so we have something to fork */