Take the 2-minute tour ×

My application similar to hypotetical program:

for(;;) {
    p[i] = malloc(random_number_between_1000_and_100000());
    p[i][0]=0;  // update

Has no memory leaks but on my system, the consumption of memory (top, column VSS) grows without limits (such as to 300% of available physical memory). Is this normal?

Updated - use the memory for a while and then free it. Is this a difference?

share|improve this question
Try to really access the chunks, otherwise there's no guarantee they've been allocated. –  Bastien Léonard Nov 26 '09 at 14:41

4 Answers 4

up vote 1 down vote accepted

Try to add


at end of each loop to see if it makes difference.

The free() only deallocates memory but it doesn't give it back to OS.

share|improve this answer

The behavior is normal. Quoting man 3 malloc:


By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer. In case Linux is employed under circumstances where it would be less desirable to suddenly lose some randomly picked processes, and moreover the kernel version is sufficiently recent, one can switch off this overcommitting behavior using a command like:

       # echo 2 > /proc/sys/vm/overcommit_memory

See also the kernel Documentation directory, files vm/overcommit-accounting and sysctl/vm.txt.

You need to touch (read/write) the memory for the Linux kernel to actually reserve it.

share|improve this answer
Of course technically vm overcommit is a feature, not a bug. It can be disabled, or made less optimistic. –  MarkR Nov 26 '09 at 16:23
First time I've encountered this was 8years ago when I friend allocated 1GB on a machine with 128MB Ram. Everything worked flawlessly, until somebody decided to take a look over his source code. We are all perplexed, but finally figured out the overcommit_memory feature. –  Alexandru Nov 26 '09 at 16:31

The OS usually allocates all pages as Copy-On-Write clones of the "0" page, that is a fixed page filled with zeros. Reading from the pages will return 0 as expected. As long as you only read, all references go the the same physical memory. Once you write a value the "COW" is broken and a real, physical, page frame is allocated for you. This means that as long as you don't write to the memory you can keep allocating memory until the virtual memory address space runs out or your page table fills up all available memory.

share|improve this answer

As long as you don't touch those allocated chunks the system will not really allocate them for you.
However you can run out of addressable space which is a limit the OS imposes to the processes, and is not necessarily the maximum you can address with the systems pointer type.

share|improve this answer

Your Answer


