Memory Leaks

Applications Programming
1

Suppose I have a main() function with only one malloc statement allocating say some 1 gb memory. Also say my system has 1 gb of ram.

main()
{
    malloc(1gb)

    return(0)
}

The program above exits without freeing the memory.

In this case will the 1 gb of heap memory be returned to system on above process termination or has the heap memory permanently leaked and will be available only on system reboot?

I mean if say we start some another process or say the same process again then will they be able to get the 1 gb if heap again?

2

All memory allocated by a process is returned to the system when the process terminates.

A very small amount of memory will remain after the process terminates that indicates the status of the terminated process. That memory will be released when the process that started the terminated process either gathers the exit status of its dead child (by calling something like wait()) or terminates.

1 Like
3

Consider this; all malloc() does is either give you memory that already belongs to the process, or change the size of the heap segment so it can give you even more. free() never returns it to the system -- it just puts it in a list so malloc() knows what to recycle next time.

The heap segment ceases to exist when the program quits, just like the code segment, data segment, stack segment, and all the other segments.

1 Like
4

In the open source world, that hasn't been true for about 10 years. Linux (glibc), OpenBSD, NetBSD, and FreeBSD all return memory to the system under certain circumstances (such as free()ing a massive chunk).

I have no idea how the proprietary libcs behave.

The second half of this post about the exact same topic contains excerpts from a couple of malloc/free implementations, with links to their sources: http://www.unix.com/302717047-post9.html

Regards,
Alister

1 Like
5

Thanks all for the reply.
The link HowStuffWorks "The Basics of C Programming" also helps stating:
What happens if I forget to delete a block of memory before the program terminates? When a program terminates, the operating system "cleans up after it," releasing its executable code space, stack, global memory space and any heap allocations for recycling. Therefore, there are no long-term consequences to leaving allocations pending at program termination.

6

This is contrary to what I have read...since the freed memory return to the OS pool only when the process exits. I maybe wrong but this seems to contradict what I read in this book...besides frequent garbage collection by the OS is going to make the kernel sweat. In fact whatever I understood about runtime memory allocation from that book is exactly what Corona688 posted.

7

Then what you read is either a pedagogical simplification or an oversight. Since the statement, "free() doesn't return memory to the system", is true for 4.4BSD [see Note 1], and since The Design and Implementation of the 4.4BSD Operating System is the predecessor of The Design and Implementation of the FreeBSD Operating System, perhaps the statement originated in the earlier work and was carried over unintentionally.

The first book was published on May 10, 1996. The second on August, 12, 2004. FreeBSD began returning memory (when possible) to the kernel when it adopted Poul-Henning Kamp's phkmalloc back in September 16, 1995, before either book hit the shelves. From malloc.c revision 1.3:

1.3     ! phk       927:     }
        !           928:     if (!pf->next &&
        !           929:       pf->size > malloc_cache &&
        !           930:       pf->end == malloc_brk &&
        !           931:       malloc_brk == sbrk(0)) {
        !           932:        pf->end = pf->page + malloc_cache;
        !           933:        pf->size = malloc_cache;
        !           934:        TRACE(("%6d U %p %d\n",malloc_event++,pf->end,pf->end - pf->page));
        !           935:        brk(pf->end);    <-- memory returned here
        !           936:        malloc_brk = pf->end;

From phkmalloc's author himself in Malloc(3) revisited:

In a commit later that year, revision 1.7, December 11, 1995 (still before either book was published), mmap improvements were made to increase the odds of returning memory to the kernel. However, phkmalloc never used mmap to directly satisfy memory allocation requests. Instead, it used mmap to place the page directories (housekeeping data structures) outside the heap. From the commit message:

Revision 1.93, January 13, 2006, of malloc.c replaced phkmalloc with jemalloc, whose malloc/free can use mmap/munmap. Among other benefits, this increases the opportunities to return memory to the kernel.

For your convenience: FreeBSD malloc.c cvs history

Regards,
Alister

Notes:
1) In the malloc.c cvs history, we see that the initial version of FreeBSD malloc.c came from 4.4BSD Lite. Looking at the code confirms that revision of free() never returns memory to the system.

3 Likes
8

Wow thank you alister...that is truly amazing

9

In addition to what has already be answered, note that your C sample program uses no (significant) RAM. Allocating memory essentially means reserving virtual memory space which is a very lightweight operation and is unrelated to your RAM size.

10

Beaten...lol. That's what I was going to post. Malloc 1gb of memory does "nothing" until you touch the pages. Replace that statement with, for example, calloc, though, and...well...just go ahead and do it, if you only have 1gb of RAM, get some coffee first, lol.

P.S. "nothing" is a grave over-simplification, but...while it does create page mappings for the process and reserves address space, it doesn't actually back any of the pages until they are touched.