Memory leaks are often thought of as failures to release unused memory by a computer program. Strictly speaking, that behaviour is just more memory consumption. A memory leak occurs when the program loses even the ability to free the memory. Either behaviour diminishes the performance of the computer, as it becomes unable to use all its available memory.

Memory leaks are a rather common error in programming, especially when programming in languages that have no automatic embedded garbage collection (GC), like C and C++, which deeply rely on pointer operations. This has led to the development of a number of tools to detect and prevent this problem from happening. Purify, Valgrind, Insure++ and memwatch are some of the most popular tools for discovering memory leaks in C and C++ programs. It should be noted that GC for C and C++ programs can be included as facilities and are not inherently lacking; GC facilities, if included programmatically, can be used like any other programmatic feature, as Bjarne Stroustrup (the inventor of C++) points out about C++. However GC will not account for all of the programming errors that cause memory leaks.

The main issue is that it is normally a component of the operating system which is responsible for managing memory, and so the result of a memory leak is usually an ever growing amount of memory being used by the system as a whole, not merely by the erroneous process/program. Eventually, all (or too much) of the available memory may be allocated (and not freed) and the entire system (or critical subsystems) can stop working correctly.

In languages providing automatic memory management, like Java, C# or LISP there can be memory leaks too. The memory management does not free an object that is strongly reachable. This is the case if still one or more (also strongly reachable) references exist for the object. (For example, storing an object in a Vector object in Java and later losing/forgetting about the index). The developer is responsible for cleaning up references after use. Nevertheless, automatic memory management is more convenient for developers, as they don't need to implement freeing routines or worry about the sequence in which cleanup is performed. Automatic memory management does impose a small performance overhead with all the extra checking.

Simple example in C

Here is a program that deliberately leaks memory.

int
main(void)
{
   char *string1 = malloc(sizeof(char)*50);
   char *string2 = malloc(sizeof(char)*50);
   scanf("%s", string2);
   string1 = string2; // here the memory created above for string1 is lost "leaked"
                      // it is not pointed to by anything anymore, 
                      // so it cannot be explicitly freed

   free(string2); //this will be successful
   free(string1); //this will be erroneous - attempt to free already freed memory
   return 0;

}

See also

• Memory management
• Memory debugger

External links

• short definition
• Why doesn't my application release the memory? (Java FAQ)
• Detecting a Memory Leak (Using MFC Debugging Support)
• Article "Is Your Memory Not What It Used To Be?" by Madhu M Kurup
• Article "Memory Leak Detection in C++" by Cal Erickson
• Article "Memory Leak Detection in Embedded Systems" by Cal Erickson
• Article "Fixing Memory Leaks in KDE" by Harri Porten
• Citations from CiteSeer
• Sample Chapter from Bitter Java