Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash

[Wolfram Gloger <wg@malloc.de>]

> > Oh, so you're adding/removing physical memory dynamically?
> 
> No. I don't see why you ask this. In my documentation, ulimit sets
> a limit for the *current* process, not for the whole system.

I know, but see /etc/initscript.  Together with the number of
processes (also ulimited), it effectively is a limit for the system.
Not the one you like, obviously, but nevertheless a functional one.

> > Well, either live with that or add sufficient swap space.
> 
> Wrong remark. Solaris behaves correctly, for instance (i.e. if there
> is no memory left, malloc() returns 0, without needing to set limits
> on processes).

"Correctly"?  First, I doubt that Solaris has no overcommitment -- try
a test with fork() (it should then fail unless there is enough
physical memory left for a second copy of _all_ writeable pages of the
current process).  Second, I for one would consider the absence of
overcommitment as a bad misfeature.  Good luck with the kernel bug
report.

This has been beaten to death many times.  For me the alternative is
clear: either enjoy the advantages and disadvantages of overcommitment
_or_ use "ulimit -v".

Regards,
Wolfram.