2

Say I have the following program for demonstration purposes only:

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

int main(void)
{
    char *my_memory = malloc(50000);
    int *my_int = malloc(sizeof(int));
    
    //Do other things but never free my_memory or my_int
    
    return 0;
}

According to Wikipedia:

In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations1 in such a way that memory which is no longer needed is not released. A memory leak may also happen when an object is stored in memory but cannot be accessed by the running code.[2]

Sentence #1 implies that a memory leak can be unneeded, unfreed memory. However, many, many programmers I've worked with have stated that "there is no memory leak because the OS frees the memory." These programmers believe that memory leaks only occur if there is no longer a reference point or handle to some allocation, thus making it no longer accessible and no longer able to be freed.

As far as I know, it is true that the OS does free the memory, in regards to modern macOS, Windows, and Linux.

I've used AddressSanitizer, Dr. Memory, and Valgrind; they flag this type of program as having "memory leaks."

So my question is, is an example such as the above, where memory is allocated and not freed before program termination, a memory leak or not?

Community
  • 1
  • 1
the_endian
  • 2,259
  • 1
  • 24
  • 49
  • https://stackoverflow.com/questions/273209/are-memory-leaks-ever-ok – Mat Dec 08 '19 at 06:43
  • @Mat Though the discussion is similar, my question is fundamentally different - it deals with the actual accepted definition of what a memory leak is, rather than *once that has been decided, is a memory leak then acceptable in some circumstances?* – the_endian Dec 08 '19 at 07:10
  • There isn't an accepted definition - you already found that out too in your question. – Mat Dec 08 '19 at 07:15
  • @Mat I think the real question here can be reduced to - "Is a memory leak viewed from the perspective of a process, or the entire system, including the OS?" I don't think it's possible to be "yes and no" at the same time, but for example, it's "yes" when the program is considered as a standalone system. It's "no" when the OS is part of the picture. – the_endian Dec 08 '19 at 19:13

2 Answers2

2

Yes and no.

Most programs are written with the expectation that they free their memory before termination. But most operating systems are written to not assume anything about the memory used by applications, so they will indeed reclaim that memory after a program has terminated.

It's not that freeing memory in your application code always directly returns it to the operating system anyway--typical memory allocators will just mark the memory as unused and available for use in a subsequent call to malloc().

There are also programs written with the express intent of not freeing their allocated memory. This is a simple, effective way to implement very high performance deallocation, because the operating system sees the allocated memory as a small number of large chunks and takes much less time to deallocate those chunks than if the application were to explicitly free each of them (assuming they were allocated as a much larger number of small objects from the application perspective). This is a valid approach, though it does complicate the use of some analysis tools like valgrind, so some programs avoid it by explicitly allocating and deallocating a small number of large "pools" of memory and internally dividing those up to store small objects. This "pool allocator" approach is analogous to what the C standard malloc() and free() normally do for you.

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
-2

yes this is a memory leak. each time you allocate space you must free that space when you don't need it any more. since allocated memory can be shared between threads, it's hard for OS to detect that there is no more programs that doesn't use that space any more and it will still allocated after the end of the program.

Zied ALAYA
  • 7
  • 1
  • 4