Andreas Hasenack <andreas(_at_)conectiva(_dot_)com(_dot_)br> writes:
Em Fri, Jul 05, 2002 at 10:49:54PM +0200, Matthias Andree escreveu:
I can't believe I'm reading this, I truly hope I'm mistaken. I think you
are talking about the situation where one has the overcommit bit
Linux always overcommits (unless I missed the change).
$ cat /proc/sys/vm/overcommit_memory
Default setting, I didn't touch it (2.4.18).
I wrote: Linux always overcommits. Which of the three words is
Don't believe it? Try "swapoff -av" and then allocating as much memory
as you have in one malloc chunk. What do you expect? NULL. Right. What
do you get? NULL or some address?
alloca() stinks. Apart from that, for the user, it makes no difference
Yep. And the manpage is sort of wrong.
Linux manpages stink because they're usually maintained by some other
person than the code maintainer, out of date, incomplete, whatever.
if the program exits uncleanly because it fails to do a graceful exit
(memory pressure may even have increased, the "graceful exit" may need
more memory) or because alloca() returned a pointer to an overcommitted
There is a security implication here, writing/reading where you shouldn't.
Let's delve deeper: If and only if the system knows the first access to
that area will reliably trigger SIGSEGV, there is no security issue.