Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When a program terminates what happens to the memory allocated using malloc that is not free'ed?

Say I have the following program

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

int main(void) 
{
    int * i;

    if ((i = malloc(sizeof(int) * 100)) == NULL) {
        printf("EROOR: unable to allocate memory \n");
        return -1;
    }

    /* memory is allocated successfully */

    /* memory is not free'ed but program terminates */
    // free(i);

    return 0;
}

The above program calls malloc to allocate some memory and does not call free to de-allocate it. And the program terminates without de-allocating the memory.

Valgrind clearly detects a memory leak.

<snap>
==14209== HEAP SUMMARY:
==14209==     in use at exit: 400 bytes in 1 blocks
==14209==   total heap usage: 1 allocs, 0 frees, 400 bytes allocated
==14209== 
<sanp>
==14209== LEAK SUMMARY:
==14209==    definitely lost: 400 bytes in 1 blocks
==14209==    indirectly lost: 0 bytes in 0 blocks
==14209==      possibly lost: 0 bytes in 0 blocks
==14209==    still reachable: 0 bytes in 0 blocks
==14209==         suppressed: 0 bytes in 0 blocks
==14209== 
==14209== For counts of detected and suppressed errors, rerun with: -v
==14209== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Question:

When the program terminates, what happens to the memory that was allocated but not free'd?

Update: Consider that this code is being executed on different operation system - say windows, linux, solarix, macos, etc. Is there any difference in the behavior of this code during its termination?

like image 901
Sangeeth Saravanaraj Avatar asked Apr 19 '12 07:04

Sangeeth Saravanaraj


3 Answers

The other answers tell you the two important things:

  1. Yes, the memory is reclaimed by the OS, so you don't technically need to free() it.
  2. It's good practice to free everything you malloced anyway.

However, it's important to say why it's good practice to free() everything you've malloced. In my view:

  1. Habit: If you get in the habit of freeing whenever you've malloced, you won't accidentally forget when a memory segment isn't around for the lifetime of the program.
  2. Maintainability: If someone comes along to refactor your program so that a segment of memory is no longer around for the lifetime of the program, the presence of cleanup code in the original will mean that it's very likely that the refactored version also includes the cleanup code. For me, this is the most important reason.
  3. Debugging: If we expect that all memory is cleaned up correctly, then spotting memory that's actually leaking is much easier.
like image 111
Timothy Jones Avatar answered Sep 28 '22 11:09

Timothy Jones


O.S. will reclaim the memory not free'd up.

But is a good practice to free all memory allocated by malloc

like image 39
DonCallisto Avatar answered Sep 28 '22 10:09

DonCallisto


The memory is reclaimed by the Operating system once your program exits.
The OS doesn't understand that your program leaked memory, it simply allocates memory to the program for running and once the program exits it reclaims that memory.

However, other resources like file descriptors may/may not be recalimed by the OS causing a resource leak.

So it is a good practice that a program should cleanup all the resource it utilized before exiting.

like image 34
Alok Save Avatar answered Sep 28 '22 09:09

Alok Save