Memory leak

Memory leak (English memory leak, sometimes memory hole or short memleak ) denotes an error in a computer program, which means that an ongoing process a memory area is occupied but this can neither free nor use.

• 3.1 Example for people without programming knowledge
• 3.2 C
• 3.3 C
• 3.4 Automatic garbage collection

Problem

Since unrestricted growth of the exclusive use of a limited resource is impossible to provide a memory leak problem of software development dar. This may affect in multitasking environments other processes, which themselves have no memory leak. In any case, at sufficiently long running time, the memory leak will lead to undesirable phenomena. With the end of the process and its memory claim is abandoned in modern operating systems.

The question of whether a program has a memory leak is not decidable because the set of Rice.

Solutions

The operating system is very limited in a position to remedy the situation, as it can usually do not have sufficiently deep insight into the internal data structures of the processes. Easy to implement, the restriction of the right to store a value that should satisfy the requirements of each process, so that in case of a memory leak, at least no other processes are impaired. There are also other approaches are feasible, which is decided by heuristics which of the processes is the one who might have a memory leak, precisely in order to end the then.

In the possible approaches to memory management is helpful to distinguish between two alternatives:

There are following approaches to avoid memory leaks:

In the following, these alternatives should be considered briefly.

Automatic garbage collection

If the runtime environment used provides automatic garbage collection, can be occupied and used by a process memory. Once the runtime detects that a memory area that is not accessible, this will be released. Not more accessible in this context means that no valid variable reference exists to the allocated memory area more. However, in the general case, this approach is unsatisfactory, because wrongly stored references can not be detected.

Explicit memory deallocation

In contrast to the automatic garbage collection, the application developers in other programming languages ​​(C, C or Pascal ) implement the memory management itself. That is, it can be dynamically requested memory areas used and then re-enable. The memory allocation is done explicitly provided by the programmer sites and is not linked to the existence of a variable reference, which in addition to the difficulties of automatic garbage collection creates errors.

Systematic tests

Through systematic testing using appropriate tools that can determine with any degree of certainty which memory areas are allocated to a memory leak, you can avoid the problems of formal verification.

A well-known such tool is Valgrind. It examines ( on Linux systems ), the memory usage of a process at run time. In a few obvious cases it may be sufficient to just observe the memory usage of a process over time.

Formal Verification

Through a correctness proof can be memory leaks can be discovered in particular. However, this method is very time consuming and requires highly skilled personnel. Specialising in memory leaks question can be examined computerized.

Examples

The best known example for missing automatic memory management is the language C. New memory is requested by the malloc function in C programs. Thereby malloc returns a pointer to the beginning of the corresponding memory area. This reference is necessary using a suitable code to free the memory again (using the free function). If the needle is lost or changed, the process can not access that memory and thus not release it.

Example of people without programming knowledge

This example is intended to show people without programming knowledge of how a memory leak can occur. It is a free thought up example.

The example shows a detail of a pseudo program code for controlling an elevator. This part of the elevator program is always executed when someone presses a button for a floor in the elevator.

When a button is pressed:   Reserve memory to store the desired floor number   Write the floor number in the reserved memory   The car is already at the desired floor?   If so, there is nothing to do: Return from Subroutine   Otherwise:     Wait until the car without further tasks     Drive to the desired floor     The free memory in which the desired floor number was stored This program has a memory leak. If a floor is selected and the lift already located on this floor, the memory that was allocated in the second line of the program, never released.

This has no immediate effect. Lift users press seldom the floor, where they are currently located knob, and the lift could have as much free space that this would work hundreds or thousands of times without any problems. However, the elevator could eventually have depleted its entire memory. This could take months or years and is therefore very difficult to find out by testing.

The consequences in this case would be unpleasant. The lift could stop responding to user input and no longer continue. If the program also needs memory to open the doors, someone could be imprisoned by the error in the lift, because there is no more memory is available to open the doors.

The memory leak would exist only as long as the program runs. If the lift is switched off, the program would stop. After reactivation, the program would restart, the memory would be freed, and the slow process of Speicherleckens would start again.

C

The following example illustrates the formation of a leak on the basis of a memory implemented in C program:

# include     int main ( void)   {       int * a, * b; / * Pointer to a memory area interpreted as an integer * /         / * Allocate memory for pointers. * /       a = malloc ( sizeof ( int) );       b = malloc ( sizeof ( int) );         * a = 5; / * Write the value " 5" in the referenced by a memory area * /       * b = 3; / * Write the value " 3" in the memory area referenced by b * /        a = b; / * Assigns a pointer to the destination of the pointer b. * /         / * A and b are now reference the same memory area. The previously referenced by a        * Memory is therefore orphaned and can no longer be released. At this point        * Create a memory leak.        * /         free (b); / * Returns the free memory referenced by b * /       free (a); / * A and B point to the same storage area, however, the already                    * Has been released in the previous line.                    * The behavior is no longer defined.                    * /         return EXIT_SUCCESS;   } From step a = b, it is no longer possible to access the memory region pointed to a previously. The area can then regularly no longer be released from the program.

C

Memory leaks in C created exactly as under C. Another source of error that does not occur in C, is the use of the wrong delete operator. If an array of objects requested, this array must be freed with the delete [ ] operator. The normal operator delete causes the destructor only the first object called, but the memory of the entire array is released. For all other objects, the destructor is not called. If the destructor dynamically unallocated memory is released ( as in the example ) occur memory leaks. Only the delete [ ] operator calls for all objects in the array to the destructor and then outputs the memory of the array free.

Class Object   {     int * m_Value;     public:     Object ()     {        m_Value = new int;        * m_Value = 42;     }       virtual ~ Object ()     {        * m_Value = 0;        delete m_Value;        m_Value = NULL;     }   }; Correct: memory for 5 objects of type int requested. The memory is completely released

Int * pi = new int;   delete [ ] pi; False: Only the destructor of the object po is called. Memory leak, because the destructor is not called up for po po.

Object * po = new Object;   delete po; Correct: The destructors of all five objects are called. The entire Unallocated memory is freed.

Object * po = new Object;   delete [ ] po; Automatic garbage collection

The following example shows that the approach alone of automatic garbage collection is not sufficient to detect memory leaks:

Public void generating memory leak () {    List numbers = new ArrayList <> ();    for (int i = 1; i < 10000; i )      nummern.add (i); } One can clearly see that the memory requirement grows constantly. Assuming that the increase in memory requirements is not the purpose of the program itself, so it is a memory leak, since no read access takes place on the list entries. This error would be quite easy to detect by static analysis, but while the graph of references and memory areas the error can not be seen.