[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Out of memory?

John Goerzen wrote:
>Brian A May <bmay@dgs.monash.edu.au> writes:
>> Hello,
>> 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
>of segfault?

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

char *program_name;

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 <bmay@csse.monash.edu.au>
>> -- 
>> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or

Brian May <bam@snoopy.apana.org.au>

Reply to: