Jump to content

Memory leak: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
No edit summary
Derrick Coetzee - Robot-assisted disambiguation: Automatic garbage collection
Line 1: Line 1:
'''Memory leaks''' are often thought of as failures to release unused [[computer memory|memory]] by a [[computer program]]. Strictly speaking, that behaviour is just 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 often thought of as failures to release unused [[computer memory|memory]] by a [[computer program]]. Strictly speaking, that behaviour is just 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 [[programming language|languages]] that have no [[automatic]] [[embedded]] [[computer memory garbage collection|garbage collection]] (GC), like [[C programming language|C]] and [[C Plus Plus|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 Plus Plus|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.
Memory leaks are a rather common error in [[programming]], especially when programming in [[programming language|languages]] that have no [[automatic]] [[embedded]] [[garbage collection (computer science)|garbage collection]] (GC), like [[C programming language|C]] and [[C Plus Plus|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 Plus Plus|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.
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.

Revision as of 00:19, 3 October 2004

Memory leaks are often thought of as failures to release unused memory by a computer program. Strictly speaking, that behaviour is just 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 no memory leaks. This is more convenient for developers, but it does impose a performance overhead with all the extra checking, as well as being somewhat less flexible.

See also: memory management, memory debugger.

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 free'd

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

}