From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: I can malloc more memory than I have. Date: Wed, 28 Oct 1992 23:33:19 GMT
In article <LILJEBER.92Oct29003741@hydra.Helsinki.FI> liljeber@hydra.Helsinki.FI (Mika Liljeberg) writes:
>In article <1992Oct27.001649.26395@athena.mit.edu> alsaggaf@athena.mit.edu (M. Saggaf) wrote:
>
>> Tcsh has a bug, 'limit coredumpsize 0' does not work. bash has no
>> problem, 'ulimit -c 0' works just fine.
>
>Hmm, I'd say the bug is in the kernel. This is from fs/exec.c, dump_core():
>
>/* See if we have enough room to write the upage. */
> if(current->rlim[RLIMIT_CORE].rlim_cur < PAGE_SIZE/1024) return 0;
> ^^^^^^^^^^^^^^
> Should be just 1024, no?
No, this is correct. The rlimit is specified in blocks, not in bytes.
The upage is just that, a page, and takes up 4096 bytes. Thus we need to see
if current->rlim[RLIMIT_CORE].rlim_cur < 4 before we try and write the upage.
>Tcsh normally computes the limit like this: actual_value = (value +
>0.5) * unit. The default unit for coredumpsize is 1024 bytes.
>Therefore, limit coredumpsize 0 sets the limit to 512 bytes. This
>easy get around. If you give the unit explicitly, tcsh does not
>attempt to round it:
This could be the problem right here. Bash is setting the rlimit in
assuming that the unit is in disk blocks and tcsh is setting it thinking that
the unit is bytes.
Under bash, I type "help ulimit", and I get:
> If LIMIT is given, it is the new value of the specified resource.
> Otherwise, the current value of the specified resource is printed.
> If no option is given, then -f is assumed. Values are in 1k
> increments, except for -t, which is in seconds, and -p, which is in
> increments of 512 bytes.
-Eric
-- Eric Youngdale