This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: potential problems with malloc and calloc


David Joseph Adrian <adriand@MIT.EDU> writes:

> I was writing some test programs to learn more about dynamic memory allocation
> and I came upon some interesting behavior.  I think that in the limit of
> filling the memory on a system, malloc may be malfunctioning.  (Or it may be my
> architecture.)  Could you please help me determine if this is a gcc-thing or a
> problem of my architecture?  Has it already been fixed in a gcc update?

This is not a gcc issue.  gcc does not provide the malloc function.
That is part of the C library.  On a GNU/Linux system the C library is
provided by glibc (http://sourceware.org/glibc/).

> Problem definition:
> The test program declares a large 2-D array of integers dynamically.  malloc and
> calloc are supposed to return a NULL pointer when they run out of space, but I
> found that on some architectures, I was able to allocate more space than is
> actually on the computer with malloc, and that the computer program dies
> ungracefully in the same situation with calloc.

And this issue actually doesn't have anything to do with malloc.  The
Linux kernel overcommits memory, and then crashes the program if it
can't come up with any memory when it needs it.

You can control this behaviour by poking at the files
    /proc/sys/vm/overcommit_memory
    /proc/sys/vm/overcommit_ratio
I think that setting overcommit_memory to 2 will tell the kernel to
not overcommit.  (Please take any further discussions of this to a
Linux kernel list, not a gcc list.  Thanks.)

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]