Re: memory crash (NOT offtopic)

Ion Badulescu (
Tue, 10 Dec 1996 18:41:12 -0500 (EST)

On Tue, 10 Dec 1996, Phillip Dillinger wrote:

> You can use bash's ulimit to limit things such as core dump size, text
> memory size, etc. Like this:
> ulimit -d 1024
> will limit a single process's data segment to 1M. Look at man bash for more
> options. Also, other shells have that feature.

I have some news about this - ulimiting the data segment does not work
with libc 5.4.xx (and I noticed it back in the 5.3.xx days), but does work
with libc 5.2.18.


moisil:~/c/test$ ulimit -Ha
core file size (blocks) unlimited
data seg size (kbytes) 6144
file size (blocks) 1048576
max memory size (kbytes) 8192
stack size (kbytes) 1024
cpu time (seconds) 360
max user processes 100
pipe size (512 bytes) 8
open files 256
virtual memory (kbytes) 7168

[fairly conservative setup for a 48MB box, except maybe for the max user
processes, but that's irrelevant in this case]

(libc 5.2.18)
moisil:~/c/test$ ./crashme &
[1] 225
[1]+ Segmentation fault ./crashme

(swapping libc's - 5.4.13 active now)
moisil:~/c/test$ ./crashme &
[1] 591
..... swapping hard... harder... even harder...
BOOM - watchdog in action, one minute or so later

#define MEM 1000000

void main()
char *p;
long i;

p=(char *)malloc(MEM);
/* fork(); */
i=MEM; while (i--) *(p+i-1)=i;

[I took out the fork on purpose, to see which ulimit was not enforced -
memory or processes]

A quick glance of the strace output in the two cases reveals a major
difference in the way the two libc's handle malloc requests. 5.2.18 uses
brk(), while 5.4.13 (and presumably all libc's with the new malloc) uses

Therefore the problem DOES exist. Even if libc is fixed, a luser can
always preload another libmalloc and crash the box.


  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.