Memory Leaks

Dec 18 2011

by Amr Elroumy

Definition

A memory leak is a particular type of memory consumption by a computer program where the program is unable to release memory it has acquired. The result is that the used memory is not cleared for use by other computer programs, and thus diminishes the operating capacity of the computer.

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 source code. However, many people refer to any unwanted increase in memory usage as a memory leak, though this is not strictly accurate.

A memory leak is a bug. Symptoms can include reduced performance and failure.
A memory leak can be fatal in systems, which has a rather small resource of memory like embedded systems or portable devices.

Causes of memory leaks

Just about any type of program can be the source for memory leak. In some cases, it may be an application program, such as a database, that resides on the hard drive. At other times, the cause of the memory leak could be one of the essential program files that drive the operating system for the computer. Generally, the malfunction within the application is the result of some sort of invasion into the suitable program, such as a virus or bug.

Even if the memory leak is small, if the program containing the leak is run it will cripple the system gradually as it incrementally takes memory from the system without returning it back. Over time, the amount of available memory becomes so limited that other applications are unable to obtain resources to launch or perform necessary functions, and begin to become inoperable. The result is that the system simply shuts down and no application can run.

Here’s an example from Wikipedia:

A layman’s(simple) example

This example, written in pseudo code, is intended to show how a memory leak can come about, and its effects, without needing any programming knowledge.

The program in this case is part of some very simple software designed to control an elevator. This part of the program is run whenever anyone inside the elevator 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

The memory leak would occur if the floor number requested was the same floor that the lift is on; the condition for releasing the memory would be skipped. Each time this case occurs, more memory is leaked.

Cases like this would not usually have any immediate effects. People do not 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 hundreds or thousands of times. However, the lift will eventually run out of memory. This could take months or years, so it might not be discovered by thorough testing.

The consequences would be unpleasant; at the very least, the lift would stop responding to requests to move to another floor. If other parts of the program need memory—say to open the door—then someone may be trapped inside, since the software cannot open the door.

The memory leak lasts until the system is reset. For example: if the lift’s power were turned off the program would stop running. When power was turned on again, the program would restart and all the memory would be available again, and the slow process of leaking would start again.

How to find a memory leak

To locate a memory leak, use the following process:

1. Find the memory leak – Detect the presence of a memory leak in the system. You should be able to identify a specific process, but demonstrating an overall increase in committed system memory can qualify a memory leak as well.
2. Isolate the memory leak – Determine the exact location in the source code where the un–freed allocation occurs. This can be a lengthy and tedious process, requiring specific tools, trial–and–error, and teamwork with the original author of the code.
3. Fix the memory leak – After the first two steps are completed, this is easy. Fixing the memory leak usually involves adding some code to free the memory in the questionable code path.

The information that can be gathered in the first step becomes very helpful in completing step 2 and step 3.

You can spot a memory leak when you detect an unexplained increase in either committed system memory—memory used by various applications—or in memory owned by a specific application.

Remember that only unexpected increases in memory usage suggest a memory leak. This means that some applications require grabbing more memory during their runtime. Thus, if you check memory in some of these applications after starting them for the first time and check it again after doing a cumbersome task with them, the memory page number increases. In this case, however, it is an expected increase it needed to allocate some memory to perform the task.

The best method of determining whether a memory leak exists is to perform the same operation multiple times within a single application. An application must allocate temporary memory to perform a new task for the first time. Thereafter, the applications can either re–use existing allocated memory or re–allocate the same amount of memory if it was already freed. In either case, the total number of allocated pages should not increase at a value greater than the previous increase.