>Date: Fri, 14 Feb 1997 10:25:42 -0500 (EST)
>From: "John F. Woods" <jfw@jfwhome.funhouse.com>
>
>Someone whose name I've lost hypothesized that csh's "limit stack 512"

David Brownlee <david@mono.org>

>was calculating the limit in bytes, rather than kbytes (causing
>programs not to function thereafter).  It's more interesting than
>that.  csh does, in fact, multiply numbers without explicit units by
>the appropriate unit, but it also adds a fuzz factor since it's using
>floating point numbers, so it ends up setting the stack limit to (512
>+ 0.5) * 1024, or 524800 bytes.  This ends up causing exec'ed programs
>to generate an abort trap.

Ick.  csh (and sh and ksh, if they do the same) should 1) avoid FP,
and 2) round up to the next page.  setrlimit() should also
sanity-check and/or round up the values itself.

>It turns out that *any* stack limit which is not a multiple of 4K
>causes this.  (Try 513k, with the k!)  I believe that kern_resource.c
>is properly doing the page-round when it figures out what to do to
>the memory map, but that exec_aout.c does the calculations without
>the appropriate page rounding.  (I didn't spend enough time reading
>exec_aout to identify the incorrect code, though.)

There is already a PR out on this; see kern/1439.  While you're at it,
check out kern/2807 (default set too low) and bin/3045 (no minimum).
-- 
Mike Long <mike.long@analog.com>     <URL:http://www.shore.net/~mikel>
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil