Memory leak

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 69.253.219.80 (talk) at 20:40, 30 May 2006 (Removed Porn Link). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Jump to navigation Jump to search

A memory leak is a particular kind of unnecessary memory consumption by a computer program, where the program fails to release memory that is no longer needed. The term is somewhat of a misnomer, since memory is not leaked or lost from the computer, but rather no longer available for use.

As is noted below, a memory leak has similar symptoms to a number of other problems, and generally can only be diagnosed by a programmer with access to the original program code; however many people are quick to describe any unwanted increase in memory usage as a memory leak, even if this is not strictly accurate.

Consequences of a memory leak

A memory leak can diminish the performance of the computer by reducing the amount of available memory. Memory allocation is normally a component of the operating system, 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 or program. Eventually, in the worst case, too much of the available memory may become allocated and all or part of the system or device stops working correctly or the application fails.

Memory leaks may not be serious or even detectable by normal means. In modern operating systems, normal memory used by an application is released when the application terminates. This means that a memory leak in a program that only runs for a short time is rarely serious.

Cases where leaks are much more serious include

  • where the program is left running, and consumes more and more memory over time (such as background tasks, but especially in embedded devices which may be left running for many years);
  • where the program is able to request memory (e.g. shared memory) that is not released, even when the program terminates;
  • where the leak is happening inside the operating system
  • where memory is very limited e.g. in an embedded system or portable device

A layman's example

This example is intended to show how a memory leak can come about, and its effects, without needing any programming knowledge. Please note that this is a fictitious example.

The program in this case is part of some very simple software designed to control a lift (elevator). This part of the program is run whenever anyone inside the lift presses the button for a floor.

When a button is pressed:
  Get some memory, which will be used to remember the floor number
  Put the floor number into the memory
  Are we already on the target floor?
  If so, we have nothing to do: finished
  Otherwise:
     Wait until the lift is idle
     Go to the required floor
     Release the memory we used to remember the floor number

This program may look simple enough, but it does have a memory leak. Consider the case where the lift is already on floor 3, and button 3 is pressed. We get some memory, and never give it back. Each time this happens, we leak a little more.

This will not have any immediate effect. People don't often press the button for the floor they are already on, and in any case, the lift might have enough spare memory that this could happen a hundred or a thousand times. But eventually the lift will run out of memory. This could take months or years, so it might never be discovered by even the most thorough testing.

The consequences in this case would be unpleasant; at the very least the lift would stop responding to requests to move to another floor. If the program needs memory to open the lift door, then someone may also be trapped inside, since there is no memory available for that door opening.

Notice that the memory leak would only last as long as the program was running. For example, if a power cut affected the lift, then when the power came back, the memory would all be available and the slow process of leaking would have to start again.

Programming issues

Memory leaks are a common error in programming, especially when using languages that have no automatic garbage collection, such as C and C++. Typically, a memory leak occurs because dynamically allocated memory has become unreachable. The prevalence of memory leak bugs has led to the development of a number of debugging tools to detect unreachable memory. Purify, Valgrind, Insure++ and memwatch are some of the more popular memory debuggers for C and C++ programs. It should be noted that garbage collection for C and C++ programs can be included as facilities and are not inherently lacking; garbage collection facilities, if included programmatically, can be used like any other programmatic feature.

Languages that provide automatic memory management, like Java, C# or LISP, are not immune to memory leaks. Although the memory manager can recover memory that has become unreachable and therefore logically useless, 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 type of memory leak, the developer is responsible for cleaning up references after use, typically by setting the reference to null once it is no longer needed and, if necessary, by unregistering any event listeners that maintain strong references to the object.

In general, automatic memory management is more robust and convenient for developers, as they don't 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 small performance overhead, and it does not eliminate all of the programming errors that cause memory leaks.

Effects of a memory leak

If a program has a memory leak and its memory usage is steadily increasing, there will not usually be an immediate symptom. Almost all systems have a certain amount of available memory, which can be consumed by programs. Eventually, the available RAM may run out. This may have one of two effects

  • On systems where all memory is in RAM, there will be an immediate failure
  • Most modern operating systems on general purpose computers use a hard disk to provide virtual memory. The effect once RAM has run out is increasing use of hard disk. The hard disk can in turn eventually run out, but usually the performance of the application and/or system will have become so slow that they will be considered to have failed before that point.

If a system crashes simply because an application has continually asked for more memory, this would be considered poor system design or a bug. What will normally happen is that the program will eventually ask for memory and be refused, either because there is no more or because a per-application limit has been reached. What happens next depends on the program, and can include:

  • The application terminates itself, perhaps with an error message;
  • The application tries to recover from the error. In fact this is usually unsuccessful, because memory would be needed to do that, and the application has by definition lost track of how it could free the leaked memory. However, some applications will start by reserving a safety area of memory, which is freed if a failure occurs to allow some limited recovery.
  • The application assumes that the request for memory has succeeded, and continues on this basis. This will typically result in an access violation but in some cases may result in damaging information belonging to this or (in primitive systems) some other application.

Is it a memory leak?

Note that constantly increasing memory usage is not necessarily evidence of a memory leak. Some applications will store ever increasing amounts of information in memory (e.g. as a cache). 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. In other cases, programs may require an unreasonably large amount of memory because the programmer has assumed memory is always sufficient for a particular task; for example, a graphics file processor might start by reading the entire contents of an image file and storing it all into memory, something that is not viable where a very large image exceeds available memory.

To put it another way, a memory leak arises from a particular kind of programming error, and without access to the program code, someone seeing symptoms can only guess that they might be a memory leak. It would be better to use terms such as "constantly increasing memory use" where no such inside knowledge exists.

The term "memory leak" is evocative and non-programmers especially can become so attached to the term as to use it for completely unrelated memory issues such as buffer overrun.

Simple example of unreachable memory in C

Here is a C function that deliberately leaks memory by losing the pointer to the allocated memory. Since the program loops forever calling the defective function, it will eventually fail when no more memory is available to the program.

int f(void)
{
    char* s;
    s = malloc(50); /* get memory */
    if (s==NULL) return 1; /* no memory available */
    else
    {   /* memory available */
        return 0;  /* memory leak - see note below */ 
    }
    /* 
     * Memory was available and pointed to by s, but not saved.
     * After this function returns, the pointer is destroyed, 
     * and the allocated memory becomes unreachable
     *
     * to "fix" this code, you would add the statement "free(s)" to
     * the else block before the "return 0" statement
     */
}
int main(void)
{
    /* this is an infinite loop calling the above function */
    while (1) f(); /* This function call will fail to malloc sooner or later */
    return 0;
}

See also