>Let's say you've got a system with 4M RAM and 2M swap. You've got one
>really big C file to compile. Let's say GCC needs 7M to compile this
>one file. So, it starts up, and when it tries to access the 7th meg,
>GCC gets a signal 11 and dies.
>Is this a clear indication of a bug? Where is the bug?
>On this system, this file will reliably cause GCC to crash. On
>another Unix system, when GCC tried to malloc() more memory than the
>system had, it would say "oh, I don't have enough memory", and would
>terminate normally. On Linux, malloc() basically never fails --
>instead, your program crashes when you actually try to *use* the
>memory you don't have, so you'd get something like a "signal 11".
>This is exactly the problem being discussed under the "linux is
>creating memory" thread.
No. The probelm with "linux is creating memory" is that none of the
people who complain about the behaviour has actually even *tested* it,
at least not with a real program. Why don't you?
Linux malloc *does* return NULL. Really.
Gcc won't get SIGSEGV because the machine runs out of memory. Really.
Most of the discussion in "linux is creating memory" thread has been
pure and stupid flamage, often without ever testing the behaviour, and
often with people reading some standards text and trying to work out
something that the standard doesn't really cover.
How about testing the following simple program:
int main()
{ printf("%p\n", malloc(1024*1024*1024)); }
(and no, it's not a strictly conforming program, dammit, stop being so
fixated by standards).
The kernel *does* overextend it's memory use in certain circumstances,
and yes, it's a bit too easy to do it, but no, I'm not stupid. And when
it does overextend its resources, it clearly tells you so: *if* it ever
kills a program due to not having memory, it will clearly say so with a
nice message like "Out of memory for XXX." where XXX is the name of the
program it will kill, and then it will kill it with SIGKILL, not
SIGSEGV.
And believe me: by the time you see this message, you will probably have
noticed it yourself for quite a while because the kernel has done a lot
of work trying to find free pages (throwing out code pages etc), and the
machine hasn't exactly been responsive for a while. Often for *quite* a
while.
Oh, you can get SIGSEGV's for programs when memory is tight, just
*because* malloc will possibly return NULL, and not all programs will
check the return value (I suspect this may be worse in places where you
don't malloc() anything explicitly, but depend on the library or
language features like "new" to do it for you). gcc should be pretty
good at not doing this, though.
Linus
by