[2] A memory leak has symptoms similar to a number of other problems and generally can only be diagnosed by a programmer with access to the program's source code.
A related concept is the "space leak", which is when a program consumes excessive memory but does eventually release it.
This means that a memory leak in a program that only runs for a short time may not be noticed and is rarely serious.
People do not often press the button for the floor they are already on, and in any case, the elevator might have enough spare memory that this could happen hundreds or thousands of times.
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.
Resource acquisition is initialization (RAII) is an approach to the problem commonly taken in C++, D, and Ada.
The C++ version requires no explicit deallocation; it will always occur automatically as soon as the object array goes out of scope, including if an exception is thrown.
These include open files, open windows, user notifications, objects in a graphics drawing library, thread synchronisation primitives such as critical sections, network connections, and connections to the Windows Registry or another database.
The flaw with this model is that it does not cope with cyclic references, and this is why nowadays most programmers are prepared to accept the burden of the more costly mark and sweep type of systems.
The following Visual Basic code illustrates the canonical reference-counting memory leak: In practice, this trivial example would be spotted straight away and fixed.
A well-known example of this kind of leak came to prominence with the rise of AJAX programming techniques in web browsers in the lapsed listener problem.
JavaScript code which associated a DOM element with an event handler, and failed to remove the reference before exiting, would leak memory (AJAX web pages keep a given DOM alive for a lot longer than traditional web pages, so this leak was much more apparent).
Most modern consumer desktop operating systems have both main memory which is physically housed in RAM microchips, and secondary storage such as a hard drive.
This usually causes the program attempting to allocate the memory to terminate itself, or to generate a segmentation fault.
Some programs are designed to recover from this situation (possibly by falling back on pre-reserved memory).
Care should be taken though because garbage collection points could also cause such a pattern and would show a healthy usage of the heap.
If the cache can grow so large as to cause problems, this may be a programming or design error, but is not a memory leak as the information remains nominally in use.