Editing Memory leak (section)

==Programming issues==
Memory leaks are a common error in programming, especially when using [[programming language|languages]] that have no built in automatic [[garbage collection (computer science)|garbage collection]], such as [[C (programming language)|C]] and [[C++]]. Typically, a memory leak occurs because [[Dynamic memory allocation|dynamically allocated]] memory has become [[Unreachable memory|unreachable]]. The prevalence of memory leak [[Software bug|bugs]] has led to the development of a number of [[debugging]] [[Programming tool|tool]]s to detect unreachable memory. ''[[BoundsChecker]]'', ''[[Deleaker]]'', Memory Validator, ''[[IBM Rational Purify]]'', ''[[Valgrind]]'', ''[[Parasoft]] [[Insure++]]'', ''[[DynamoRIO#Dr. Memory|Dr. Memory]]'' and ''[[memwatch]]'' are some of the more popular [[memory debugger]]s for C and C++ programs. "Conservative" garbage collection capabilities can be added to any programming language that lacks it as a built-in feature, and libraries for doing this are available for C and C++ programs. A conservative collector finds and reclaims most, but not all, unreachable memory.

Although the [[Memory management|memory manager]] can recover unreachable memory, it cannot free memory that is still reachable and therefore potentially still useful. Modern memory managers therefore provide techniques for programmers to semantically mark memory with varying levels of usefulness, which correspond to varying levels of ''reachability''. The memory manager does not free an object that is strongly reachable. An object is strongly reachable if it is reachable either directly by a [[strong reference]] or indirectly by a chain of strong references. (A ''strong reference'' is a reference that, unlike a [[weak reference]], prevents an object from being garbage collected.) To prevent this, the developer is responsible for cleaning up references after use, typically by setting the reference to [[null pointer|null]] once it is no longer needed and, if necessary, by deregistering any [[event listener]]s that maintain strong references to the object.

In general, automatic memory management is more robust and convenient for developers, as they do not need to implement freeing routines or worry about the sequence in which cleanup is performed or be concerned about whether or not an object is still referenced. It is easier for a programmer to know when a reference is no longer needed than to know when an object is no longer referenced. However, automatic memory management can impose a performance overhead, and it does not eliminate all of the programming errors that cause memory leaks.{{facts|date=February 2025}}