Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!wupost!sdd.hp.com!uakari.primate.wisc.edu!ames!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!sun!amdcad!BitBlocks.com!bvs From: bvs@BitBlocks.com (Bakul Shah) Newsgroups: comp.unix.bsd Subject: Re: getdtablesize Message-ID: <Bv7Dz7.C2o@BitBlocks.com> Date: 26 Sep 92 20:52:18 GMT References: <tlukka.717504312@vipunen.hut.fi> Organization: Bit Blocks, Inc. Lines: 24 tlukka@vipunen.hut.fi (Tuomas Lukka) writes: >I've had a couple of programs (most notably login and screen) >crash under zsh. >With gdb, I found that the reason was that they did something like >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. In 386bsd there is no fixed limit on how many open file descriptors a process may have so getdtablesize returns the current resource limit on open file descriptors; which is 2,147,483,647 or thereabouts by default in zsh. A quick fix may be to lower this limit using `limit descriptors N'. 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. Bakul Shah <bvs@bitblocks.com>