malloc() inside an infinte loop

Question

I got an Interview question , What happens when we allocate large chunk of memory using malloc() inside an infinite loop and don't free() it.

I thought of checking the condition with NULL should work when there is no enough memory on heap and it should break the loop , But it didn't happen and program terminates abnormally by printing killed.

Why is this happening and why it doesn't execute the if part when there is no memory to allocate (I mean when malloc() failed) ? What behavior is this ?

My code is :

#include<stdio.h>
#include<stdlib.h>

int main(void) {
  int *px;

  while(1)
    {
     px = malloc(sizeof(int)*1024*1024);
     if (px == NULL)
       {
        printf("Heap Full .. Cannot allocate memory \n");
        break;
       }
     else
       printf("Allocated \t");
    }
  return 0;
}

EDIT : gcc - 4.5.2 (Linux- Ubuntu -11.04)

I think it is a system protection mechanism which kills the most memory hungry process when it is in need of memory — ShinTakezou, Dec 17 '12 at 19:47
possible duplicate of http://stackoverflow.com/questions/2798330/maximum-memory-which-malloc-can-allocate — koopajah, Dec 17 '12 at 19:47
The [documentation for malloc](http://www.cplusplus.com/reference/cstdlib/malloc/) says that it will return null if the function fails to allocate the requested memory, but it doesn't say anything about the conditions under which this might occur. — Robert Harvey, Dec 17 '12 at 19:49
@koopajah : thanks for this link .. I couldn't have found that earlier — Omkant, Dec 17 '12 at 19:49
Usually programs are restricted to eat memory before the whole system comes down because of one memory hog. — Sunil Bojanapally, Dec 17 '12 at 20:19

score 1 · Answer 1 · answered Dec 17 '12 at 20:11

If you're running on linux, keep an eye on the first terminal. It will show something like:

OOM error - killing proc 1100

OOM means out of memory.

I think it's also visible in dmesg and/or /var/log/messages and/or /var/log/system depending on the linux distro. You can grep with:

grep -i oom /var/log/*

You could make your program grab memory slowly, and keep an eye on:

watch free -m

You'll see the available swap go down and down. When it gets close to nothing Linux will kill your program and the amount of free memory will go up again.

This is a great link for interpreting the output of free -m: http://www.linuxatemyram.com/

This behaviour can be a problem with apps that are started my init or some other protection mechanism like 'god', you can get into a loop where linux kills the app and init or something starts it up again. If the amount of memory needed is much bigger than the available RAM, it can cause slowness through swapping memory pages to disk.

In some cases linux doesn't kill the program that's causing the trouble but some other process. If it kills init for example, the machine will reboot.

In the worst cases a program or group of processes will request a lot of memory (more than is available in Ram) and attempt to access it repeatedly. Linux has no where fast to put that memory, so it'll have to swap out some page of Ram to disk (the swap partition) and load the page being accessed from disk so the program can see/edit it.

This happens over and over again every milisecond. As disk is 1000s of times slower than RAM, this problem can grind the machine down to a practical halt.

One more thing .. It means that malloc doen't fail not even single time in this case .. right ? because if it would have then it must have gone into if case because the return of NULL — Omkant, Dec 17 '12 at 20:26
yeah, linux malloc is lazy/optimistic by default - it won't actually reserve the memory until some time later. You can turn it off with: echo 2 > /proc/sys/vm/overcommit_memory; see section 9.6 here: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html - also be careful with that command, I did it on my machine and it instantly killed chrome :) — matiu, Dec 17 '12 at 22:53

score 1 · Answer 2 · answered Dec 17 '12 at 20:15

The behaviour depends on the ulimits - see http://www.linuxhowtos.org/Tips%20and%20Tricks/ulimit.htm

If you have a limit on the memory use, you'll see the expected NULL return behaviour, on the other hand if you are not limited, you might see the OOM reaper that you saw etc.

Mike · Answer 3 · 2012-12-17T20:34:37.427

1

But it didn't happen and program terminates abnormally by printing killed.

Keep in mind, you are not alone. In this case, you were killed by the Out Of Memory killer, it saw your process hogging the memory of the system and it took steps to stop that.

Why is this happening and why it doesn't execute the if part when there is no memory to allocate (I mean when malloc() failed)? What behavior is this?

Well, there's no reason to beleve that the if check wasn't run. Check out the man page for 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. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer.

So you think you "protected" yourself from an out of memory condition with a NULL check; in reality it only means if you got back a NULL, you wouldn't have deferenced it, it means nothing regarding if you actually got the memory you requested.

edited Dec 17 '12 at 20:34

answered Dec 17 '12 at 20:18

Mike

47,263
29
113
177

In clarifying the first question .. is this OOM out of memory is only in linux or in Windows or other versions of OS's too ? other things are explained well .. thanks – Omkant Dec 17 '12 at 20:21
@Omkant - OOM is a Linux tool, Windows has no such protection, you can kill Windows pretty easily. – Mike Dec 17 '12 at 20:24
Ohh okay I will try it on windows . One more thing .. It means that malloc doen't fail not even single time in this case .. right ? because if it would have then it must have gone into `if` case because the return of `NULL`. – Omkant Dec 17 '12 at 20:26
@Omkant - It means `malloc()` didn't return `NULL`, had it returned `NULL` then yes, your code should have caught it. – Mike Dec 17 '12 at 20:29

malloc() inside an infinte loop

3 Answers3