What is a memory leak?

Question

Obviously Wikipedia has a fair amount of information on the topic, but I wanted to make sure I understand. And from what I can tell it's important to understand the stack/heap relationship to really understand a memory leak?

So here's what I (think) I understand. Corrections are very welcome!

When you first start your program, a block of memory is allocated, say 0x000 to 0xFFF. The first part (say 0x000 to 0x011) is the code/text segment where the program code is loaded.

+--------------+ 0x011
| Program Code |
+--------------+ 0x000

Then you have the stack (say 0x012 to 0x7ff) that holds local variables, and they are stored/retrieved FIFO. So if you had something like

char middleLetter(string word){
     int len = word.length();
     return word[len/2];
}

int main(){
   int cool_number;
   char letter;
   letter = middleLetter("Words");
   ...

Then your variables would be allocated on the stack, which would look like this:

+-------------+ 0x7ff
|             |
|             |
|             |
| ...         |
| len         |
| letter      |
| cool_number |
+-------------+ 0x012

Of course, if you were allocating memory somewhere (using malloc or new), but never freeing it, then your heap could look like this, and you now have a memory leak:

+-------------+ 0xfff
|             |
| malloc(20)  | 0xf64
| malloc(50)  | 0xf32
| malloc(50)  | 0xf00
| ...         |
|             |
+-------------+ 0x800

What this means is that while you can directly access 0xf32 with pointer arithmetic, the OS/your program thinks that memory locations 0xf00-0xf46 are already taken, and won't ever use those spots for storage again, until your program is closed and the memory is freed. But what about shared memory? Wikipedia says it won't ever be released (until your computer is restarted?). How do you know if it's shared memory?

Is this a pretty good basic understanding? Is there anything I'm missing/have wrong? Thanks for looking!

Answer 1

Think of it this way. When developing in a language that requires the coder to manage memory, you need to explicitly allocate and destroy the memory for every single object your program will use. It's very easy to know when you don't create something properly, as your program will not work. It is much tougher to find and debug the cases where you don't destroy the object properly (this is known as a memory leak).

Lets take a typical application, lets say an RSS news reader. In an application like this, there are often many loops (looping through different RSS feeds, different RSS items, RSS Tags, and so on). If you have an instance where a created object is not properly destroyed (or released), every time that 'leaking' code is run, you will wind up with another abandoned object in memory. If the loop runs 1,000 times, you will have 1,000 abandoned objects taking up space. You can see how this can quickly add up to consume valuable resources.

Answer 2

In general, automatic variables in functions (subroutines) are going to be stored on the stack as well. Only 'malloc' or 'new' data allocations come from the heap. Next, heap based allocations can be freed and reused (many times) before the end of the program. The allocation system keeps track of both the in-use areas and the freed areas. Finally, a memory leak is when your program has lost track of some allocated memory without freeing it. this can happen by either writing over a pointer with a new value, or storing a pointer in a variable with limited lifetime/scope.

Answer 3

Your function variables are also on the stack usually, not the heap. In most systems, the heap is used for dynamic allocations. The usual memory leak situation is

1. Call some function F
2. F allocates (new or malloc) some memory
3. F returns to caller (no delete/free)
4. pointer pointing to the dynamically allocated memory is out of scope
   • the memory is still allocated.
   • You can't delete/free it anymore

Answer 4

Seems like you do understand it - with one exception: In your example, len is a stack variable like everything else. new or malloc create on the heap, everything else (local variables etc) is on the stack. And main's local variables are not different from any other function's variables.

Shared memory is a rather rare case, you usually don't need it and therefore you won't have it unless you explicitly ask for it (otherwise, some random other process may use the very same memory your process uses - obviously, this would break things badly).

Answer 5

It looks like you're using C++ code. In C++ local variables are put on the stack (I'm guessing that globals are too, but I'm not sure). So len in your middleLetter function would be put on the call stack as well. I recommend reading this article: http://en.wikipedia.org/wiki/Call_stack

When you use the new operator with a type, like int *x = new int; for example, enough contiguous memory is found to put an int. The pointer that you use to reference it, *x, is a local variable though. If x goes out of scope and you lose your pointer, that does not free the memory on the heap. That memory is still "used" by your program even though you now have no way to reference it. Because you cannot reference it you cannot deallocate it (or delete it).

As you continue to do this you will eventually run out of space on the heap that you can allocate to, and you're program will get close and closer to blowing up because it has no memory to work with among other problems.

Answer 6

Memory leak made simple: whenever you allocate memory with malloc/new and don't deallocate it later with free/delete after finishing using that memory... will cause a memory leak! The allocated memory will remain there and that space won't be used by your program ever again.

This is a serious problem when the leak is on a function that is called many times, rendering the leak to grow larger and larger each time the function is called.