Re: memory crash

stephen farrell (
10 Dec 1996 01:36:38 -0600

"Andrew E. Mileski" <> writes:

i imagine it would only be somewhat helpful, but has anyone thought
about adding a reserve-memory system like there is on the filesystem?
that is, x percent is put aside for access by root only, so when
someone runs a malloc bomb, at least root can login and kill the

i imagine that the weakness of this approach is that someone trying to
get at the computer can keep calling some suid program... but it still
seems like a step in the right direction. or am i missing something?


i've tried the malloc bomb now under linux, freebsd, solaris 2.5, and

NT (3.51) just swapped like mad, but the swapfile didn't get any
bigger... i didn't attempt to login as admin and kill it (don't know
how to do that sort of thing on NT without telnet daemon), so i can't
comment on that.

solaris (2.5/Sparc) just ate all ram and hung there (w/o disk activity),
useless -- now way for adminstrator to login and fix the problem
(always got failed malloc()). impressive, however, was how fast
solaris could eat all the ram... much faster than linux or freebsd
(didn't have top for NT to watch it).

linux (2.0.24) had the same response, more or less, as NT -- thrashes
like crazy. it killed my X server after a while, which killed the
offending processes. i could not log in as adminstrator becuase of
some error regarding loading an interpreter (? maybe htat was bash

freebsd (2.1.5 or 2.2?) -- well, freebsd comes installed with some shell
limits. this had the very nice affect of the process eating x amount
of memory, and then just stopping. no thrashing, no interruption to
the system. it's probably just on account of freebsd coming by
default set up 'right' so this wouldn't be an issue (not surprising in
the least).

can anyone explain such shell limits better? perhaps i'm generally
confused about how environments get passed around, but how does it
work that the admin can set up a shell variable that cannot be
overridden by the user?