Subject: Re: More ulimit stuff.
To: None <netbsd-help@NetBSD.ORG>
From: Greg Oster <oster@cs.usask.ca>
List: netbsd-help
Date: 07/20/1995 16:07:56
"Neil J. McRae" writes:
> sigh here we go again:
> 
> I set up so that procmail called the same script as my telnet in did, it
> gave me this:
> 
> time(seconds)        unlimited
> file(blocks)         unlimited
> data(kbytes)         16384
> stack(kbytes)        512
> coredump(blocks)     unlimited
> memory(kbytes)       59608
> locked memory(kbytes) 19870
> process(processes)   532
> nofiles(descriptors) 255
> 
> Which are the limits I normally use.
> 
> If I up ulimit to this:
> 
> /home/neil:neil@NetBSD>ulimit -a
> core file size (blocks)  0
> data seg size (kbytes)   16384
> file size (blocks)       0
> max memory size (kbytes) 59608
> stack size (kbytes)      512
> cpu time (seconds)       -1
> max user processes       900
> pipe size (512 bytes)    1
> open files               300
> virtual memory (kbytes)  16896
> 
> Then fvwm breaks, but procmail works!
> Someone tell me why this is happening to me!

I think I can tell you why fvwm is dying...

It's the maximum number of "open files" value that is causing the 
problem.  In /usr/include/sys/types.h, FD_SETSIZE defaults to 256. 
When fvwm creates an array of type "fd_set", the size of the array is 256. 
However:  when fvwm goes to figure out the maximum number of open files, 
it gets the answer from "getdtablesize()" (called in module.c, in the fvwm distribution, if I remember correctly), which would be 300 in this case. 
It now figures that there should be 300 values in the fd_set array 
(even though the array is only 256 in length), and ends up dying as
it tries to access elements beyond the end of the array :-( 

I encountered this problem some time ago, but havn't had the time to 
submit any bug reports :-( 

The fix:  Well, I hacked an old version of fvwm to make it work, and havn't
had time to apply a proper fix to a new version.  I suspect defining
FD_SETSIZE to be something like 2048 would probably "fix" the problem, but
it's not the best (and certainly not the most well thought out) solution.

Hope this helps...

Later...

Greg Oster

oster@cs.usask.ca
Department of Computational Science
University of Saskatchewan, Saskatoon, Saskatchewan, CANADA