Re: Out of memory?
John Goerzen wrote:
>Brian A May <email@example.com> writes:
>> What is the expected reponse when running a C program that allocates more
>> memory (as static arrays) then the system can provide?
>To be 100% precise, more virtual memory than it can provide (it will
>try swap too).
Oops! That is what I meant to say. I had about 4 to 5Mb spare RAM+swap space, and
had a static variable which was over 26Mb.
>> I would have expected that the linux kernel would give an out-of memory erro
>> message, as I believe it is the kernels job to allocate memory for
>> static variables. (either that or the startup code in the C program).
>Well, the kernel handles the request, but really the system is not out
>of memory, just one userspace program.
>> However, when I run such a program, I get a "segmentation fault" when
>> the program attempts to access a global variable.
>> Is this correct? Is this normal behaviour?
>I would have expected it to segfault before it even got to main, hmm.
>Are you sure this is the problem? What does gdb say about the point
Some here. gdb just acts like I was referencing an invalid memory
location. ie, the line where it crashed:
program_name = cp + 1;
gdb reported invalid memory location (or something) when I typed in
"print program_name" right before it crashed. program_name is a global
It caught be be surprise though, because this variable has nothing
in common with the large variable I allocated except that they are
both globals (different source module even).
(cp was allocated on the stack, hence it was OK)
Yes, I am sure that was the problem, because as soon as I removed
the global variable, my program worked. There was no way my program
could have worked with an array that big anyway (it started of being
small, but eventually I was gradually increasing its size all the
time until I lost track and made it far to big).
This seems to be very reproducable (ie it occurs exactly the same everytime).
If I get I chance, I will try to write a simple C program that crashes
in the same way, and try it on different kernel versions.
>Incidentally, you *REALLY* ought to be mallocing stuff; you can check
>the return code there.
True - however this is just a dirty hack of tcpdump to gather some
statistics, and there are a lot more things that I haven't done
properly too ;-)
>> I have a fully up-to-date slink system, and am using linux 2.2.1
>> Brian May <firstname.lastname@example.org>
>> To UNSUBSCRIBE, email to email@example.com
>> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Brian May <email@example.com>