Memory leak

Memory leak ( English memory leak , sometimes memory hole or short memleak ) denotes an error in the memory management of a computer program , which, with the result that there is a part of the memory to is occupied but this neither free are used.

Problem

Main memory is a resource that is only available in finite quantities and that cannot simply be withdrawn from a program. If a program occupies more and more main memory due to memory leaks, the performance of the computer may decline because parts of the main memory have to be swapped out. If the amount of memory that a process can use has been limited, at some point the program will no longer be able to allocate more memory and a program error will occur . In the case of operating systems with inadequate memory protection (e.g. embedded systems ), in the worst case, the overcrowding of the memory can result in parts of the operating system no longer being able to run correctly and the system crashing .

possible solutions

There are several ways to detect memory leaks:

Analysis of references to memory areas (e.g. smart pointers ); this analysis only detects memory areas that are no longer accessible.
Analysis of the source text for formal correctness .
Analysis of specific runtime situations as part of a software test.

Limitation of negative effects

The memory that can only be used by one process can be limited by the operating system. This does not fix the original bug, but it does limit the impact on other processes.

Under Linux one exists kernel function , the OOM-Killer (Engl. Out of memory killer ), which is used when all attempts failed to allocate memory. She chooses among the running processes u. a. the one with the highest memory requirement, the shortest runtime and the lowest priority and forcibly terminates it. After the process has ended, all of the main memory used by it is released again.

Automatic garbage collection

If the runtime environment used an automatic garbage ( garbage collection provides), it tries to determine which memory areas, a process can not access. If the runtime environment determines that an occupied memory area is no longer accessible for the program , it is released again. In this context, no longer accessible means that there is no longer a valid reference - with the exception of weak references - to the occupied memory area. Memory leaks can still occur if the memory is still accessible for the program, i.e. H. it keeps a reference to the memory, but no longer uses it.

Explicit memory release

In contrast to automatic garbage collection, the application developer must explicitly free dynamic memory areas again with manual memory management . If he fails to do this, for example at the end of a function, the reference to the memory that is still reserved is then deleted and the area can no longer be released.

Systematic tests

Systematic testing with the help of appropriate tools, which can determine with a certain degree of certainty which memory areas are to be assigned to a memory leak, can avoid the problems of formal verification.

A well-known such tool (on Linux systems) is memcheck from Valgrind . It keeps a list of the allocated memory areas with and at which point in the program the allocation took place. At the end of the program, it checks whether all allocated areas have been released again. In very simple or very serious cases, it may be sufficient to just observe the memory consumption of a process over time.

RAII

One programming technique that can prevent memory leaks is RAII (resource allocation is initialization). The memory area of a variable is reserved when it is initialized and automatically released again when it leaves its validity area. This has the advantage over automatic memory management that the “lifespan” of an object is usually known exactly.

RAII does not always protect against memory leaks of the second kind.

Formal verification

In particular, memory leaks can also be discovered through a correctness proof . However, this procedure is very time-consuming and requires expert knowledge. The question, which specializes in memory leaks, can also be examined with the aid of a computer using static code analysis .

Examples

C.

The best-known example of a lack of automatic memory management is the C language . New memory is requested here by functions such as malloc . They provide a pointer to the beginning of the corresponding memory area. The reference is necessary to identify the assignment and to release it again using a suitable code (the free function ) or to modify it afterwards. If the pointer is lost, the process can no longer access this memory and thus cannot release it or use it again during its runtime. A related problem is when the pointer is changed and vice versa when the memory is mistakenly deallocated multiple times .

The following example shows how such a memory leak occurs:

#include <stdlib.h>

int main(void)
{
   int *a; /* Zeiger auf einen als Ganzzahl interpretierten Speicherbereich */

   /* Speicher für Zeiger reservieren. */
   a = malloc(sizeof(int));
   /* ... */
   a = malloc(sizeof(int));   /* Zeiger auf zuvor allokierten Speicher wird überschrieben. */

   free(a);  /* Nur der zweite Speicherblock wird freigegeben --> Speicherleck */

   return EXIT_SUCCESS;
}

From the second a = malloc()it is no longer possible to access the memory area to which a previously pointed. The area can then no longer be released normally by the program.

Automatic garbage collection

The following example in Java shows that the automatic garbage collection approach alone is not enough to detect memory leaks:

private static List<Integer> nummern = new ArrayList<>();
public void erzeugeSpeicherleck() {
  for (int i=1; i<10000; i++)
    nummern.add(i);
}
// kein weiterer lesender Zugriff auf die List nummern

You can see here that the memory requirement is constantly growing, so it is a memory leak because there is no more read access to the list entries. This error would be quite easy to detect by static analysis , whereas the graph of references and memory areas does not reveal the error.

Web links

Individual evidence

↑ linux-mm.org

[1] ux-mm.org