I'm getting a little bit tired of writing
if (a = malloc(...) == NULL) {
// error code
}
I mean, is it really possible that a malloc call could fail, except in
the case of running out of virtual memory?
The *PROGRAM* can run out of virtual memory well before the *SYSTEM*
runs out of virtual memory. Sometimes particular programs (or
mortal users in general) are limited because having the whole system
come down due to the actions of one memory hog is undesirable.
This feature is sometimes called 'ulimit' (after the shell command
that sets the limits).
One real, practical example: the Exim mail transfer agent tends
(at least it did a couple of years ago when I identified this
problem) to leak a little bit of memory (something around the size
of the message headers, e.g. 2k bytes) each time it rejects a message
for syntax errors in headers. This memory is recovered when the
particular SMTP conversation terminates and the process exits (which
typically happens in less than a minute). Doesn't sound like a big
problem, right, especially for a machine with 500MB of RAM and 1GB
of swap, does it?
Now enter a spammer who establishes a connection ONCE, and sends a
quarter million spams (all rejected, and no, I did not make this
number up, I counted log entries) down that one connection over a
period of a couple of days. Now the process has leaked 500MB, the
system is swapping a lot, and since this isn't the only process
receiving junk from the same spammer, it runs out of swap space,
after having slowed down to a crawl with heavy swapping. In this
case, setting the ulimit low enough to abort the connection after
it had received an unreasonable number of messages prevented this
spammer from killing service for other people actually sending
useful mail. One process would die, the spammer would get dumped
and start up another connection, and continue getting spams rejected.
The rest of the system was relatively unaffected.
Of course, the real fix is to remove the leak, but I didn't know
enough about the internals of the code to do that.
Gordon L. Burditt