Is there a need to check for NULL after allocating memory, when kernel uses overcommit memory

memory malloc android-ndk
FL4SOF picture FL4SOF · Feb 12, 2010 · Viewed 21.1k times · Source

It is general practice to check for NULL (whether memory is successfully allocated) after a malloc(), some thing like

void *ptr = malloc(10);    
if (ptr != NULL) {  
  // do some thing usefull  
} else {  
 // no memory. safely return/throw ...  
}

with memory overcommit enabled in kernel, is there a chance of getting NULL? Should I follow the practice of religiously checking NULL for each allocation? Will malloc return NULL inspite of aggresive overcommit mechanism (I guess value 1)?

As a matter of fact Android kernel uses memory overcommit (not sure about the value, would love to know it(overcommit value) and its significance). Some of the framework source(C/C++) code in Android (might be 3rd party) doesn't check for NULL nor catch bad_alloc after allocations. Am I missing something?

There are some threads in SO regarding overcommit memory, but none of them resolved my confusion.

EDIT: If aggressive overcommit is being employed NULL wont be returned(assumption 1). When there is no physical memory available and up on trying to access the allocated memory (write in to the memory allocated), OOM will kill some process and allocates memory for the application till it gets killed in turn(assumption 2). In either case i dont see any need for cheking NULL (memory getting allocated or process getting killed). am i right in my assumptions?
Portability is not a concern for this question.

Answer

CB Bailey picture CB Bailey · Feb 17, 2010

Yes, you should still check for failures returned by malloc. In an environment that overcommits memory you will not be able to detect and recover from failures due to the environment running out of physical storage required when you write to parts of the address space that have been allocated to your program by a previous call to malloc.

However, this is not the only problem that would cause a malloc to fail in a traditional environment. A request for a particularly large block of memory when the address space of your program has become fragmented may fail even if there is potentially enough total physical memory to satisfy the request. Because there is no contiguous range of free address space malloc must fail. This type of failure must be signaled by malloc returning NULL, whether or not the environment is overcommitting memory.

Related questions

How is malloc() implemented internally?

Can anyone explain how malloc() works internally? I have sometimes done strace program and I see a lot of sbrk system calls, doing man sbrk talks about it being used in malloc() but not much more.

Read More
malloc(sizeof(int)) vs malloc(sizeof(int *)) vs (int *)malloc(sizeof(int))

I acknowledge that all three of these have a different meaning. But, I don't understand on what particular instances would each of these apply. Can anyone share an example for each of these? Thank you. malloc(sizeof(int)) malloc(sizeof(…

Read More
How do free and malloc work in C?

I'm trying to figure out what would happened if I try to free a pointer "from the middle" for example, look at the following code: char *ptr = (char*)malloc(10*sizeof(char)); for (char i=0 ; i<10 ; ++i) { ptr[i] = i+10; } ++…

Read More