From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13smp i686; Nav)
Description of problem:
"limit datasize 10m" should limit the sbrk+stack size to 10M in tcsh;
that try to brk beyond that should fail (causing brk/malloc to return 0.)
This does not work in tcsh 6.10; tested on Red Hat 6.2, 7.0, and 7.2.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2. limit datasize 5m
Actual Results: Program continues allocating memory forever.
Expected Results: Program should have died after allocating around 5M.
Attached is the source to the malloc-bomb program I used to test this.
Following that is the source to limiter.pl, a perl script that *does*
work ("./limiter.pl 5M malloc-bomb"). That limiter.pl works demonstrates
that the problem is with tcsh and not with the setrlimit() syscall.
FWIW, bash 1.14 also had this problem, but it appears to have been
corrected by bash 2.04.
Created attachment 41831 [details]
malloc-bomb.c source: program that verbosely allocates memory
Created attachment 41832 [details]
limiter.pl -- program to demonstrate that setrlimit() works correctly
The difference is that limiter.pl (and (ulimit -v) referenced
in malloc-bomb.c) use RLIMIT_AS, but (limit datasize) uses
RLIMIT_DATA. If you use (limit vmemoryuse) under tcsh
(to also use RLIMIT_AS), bash and tcsh behave exactly the same.
OTOH SUSv3 specifies:
This is the maximum size of a processâ data segment, in
If this limit is exceeded, the malloc() function shall
errno set to [ENOMEM].
In fact, RLIMIT_DATA limits memory allocated through sbrk (),
but malloc () in glibc can also use mmap (). This seems like a
violation of the standard by glibc.
That POSIX text is ancient. If one insists to have this definition of
RLIMIT_DATA, simply start the application with
in the environment. That is perfectly fine with POSIX. POSIX
specifies only that there must be one environment in which all the
rules apply. The default environment does not have this stupid
limitation which nobody wants.