Does malloc without corresponding free always produce a memory leak?

Question

Does malloc without corresponding free always produce a memory leak, or are there situations when it doesn't?

Answer 1

It depends on how you define "memory leak". If you define it as having any outstanding objects with allocated storage duration at the time of program exit, then yes, it's a leak. This is what tools like valgrind report. However, it's not a useful definition at all.

My definition of memory leak is roughly an unbounded increase in total memory consumption of the program over its lifetime despite having a bounded working set. For example, if I always have at most 10 tabs open in my browser, to the same 10 sites, but memory usage keeps increasing unboundedly, that's a memory leak. On the other hand, a program that allocates a buffer to load a whole file into memory, loads the file, prints it in reverse, then exits without freeing the memory does not have a memory leak.

One particular important case where a malloc without free is not only not-a-leak but absolutely necessary (for general code that can't make assumptions about the whole program it's running in) is any use of runtime-allocated constant tables whose generation is controlled by call_once. No matter how late you tried to free such tables, it would be possible for code (in another thread, or an atexit handler, etc.) to attempt to access it after free, and call_once type interfaces intentionally do not provide any way to synchronize any access except first call (this is how they avoid introducing unwanted acquire barriers/synchronization cost at every read).

Note that the concept of "working set" here is somewhat subjective and highly load-bearing. Often memory leaks are a matter of the software still considering something part of its working set when the user no longer considers it so.

Answer 2

A memory leak is a situation where a program allocates memory, does not free it when it is no longer in use, and loses track of its address (the value of the pointer returned by malloc, calloc or realloc).

Since the pointer is lost, the memory can no longer be freed and will stay attached to the program until it exits.

If the program exits, all memory associated with it is reclaimed by the operating system (except for rare circumstances beyond the scope of this question), so the memory leak has no consequences.

If the program executes for a long time, potentially until the system is shut down, unused blocks of memory attached to the program cannot be used for other purposes. If the amount of memory thus wasted is small, again no consequences are expected.

Conversely, if the program keeps allocating more memory and not free it, the system will run out of memory for the program to use and either return NULL for an allocation request or become unstable as it uses virtual memory to honor the requests at the expense of other programs and at the cost of lengthy swapping operations to storage devices or other compression techniques. At some point the system may kill processes at random to try and recover usable memory.

Such memory leaks are problematic and must be avoided. They are especially problematic in library functions that may be used in programs that run for extended sessions, such as web browsers, email readers, file managers, media players, program managers...

Unlike other programming languages, C does not have an embedded garbage collector that could determine which allocated blocks of memory are still in use, so it is the programmer's responsibility to keep track of all allocated blocks and free them as soon as possible. Advanced tools such as valgrind can be used to verify if all allocated blocks have been freed upon program exit. Although it is not necessary to free the memory at exit, it is good programming practice and a good way to determine if all allocated memory blocks have been accounted for.