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/h

Answer 1

A memory leak is simply dynamic memory that you allocate, but then never free. A consequence of this is that your program will slowly eat up memory over time, potentially causing a crash if you completely run out of physical memory and your swap gets completely eaten as well.

So this is technically a memory leak:

int main(void) {
    void *some_memory = malloc(400);

    // rest of program...
    // some_memory is never freed
}

But this is not:

int main(void) {
    void *some_memory = malloc(400);

    // rest of program...
    free(some_memory);
}

Of course, this is a bit of a trivial example. More commonly, memory leaks occur in loops where several chunks of memory are allocated, but not all memory is freed. A common one is if you have a dynamically allocated struct containing a pointer to a dynamically allocated string - if you free the struct but forget to free the string, that is a memory leak. But note that your OS will clean up any allocated memory when your program terminates, so it won't permanently affect your memory.

Dynamically allocating memory with functions such as malloc(), calloc(), and realloc(), but not using free(), will cause a memory leak. When you dynamically allocate memory, it is stored on the heap rather than the stack (the stack is used for static memory allocation such as local variables and the heap is used for dynamic memory allocation). When a function returns, values on the stack memory are reclaimed. However, the heap memory does not get reclaimed.

Finally, leaked memory is memory that is no longer accessible and has not been freed / de-allocated.

Answer 2

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 3

In garbage-collected systems, the term "memory leak" can sometimes seem a bit nebulous. I would offer the following definition, which is just as applicable to garbage-collected systems as to those which use explicit deallocation: A program or subprogram P has a memory leak if there exists an initial sequence of inputs S and repeating pattern of inputs P, such that:

1. Feeding the program or subprogram input S followed by P will leave the program in the same "meaningful" state as it had before P, but
2. For any quantity of memory Q, there exists some number N of repetitions, such that feeding the program input S followed by N repetitions of P will cause the program to use more than quantity Q of memory.

It is possible for a program without a memory leak to have memory usage which is unbounded with respect to the size of the input, if all of the input is in fact contributing to the program's state. For example, a program to read in an input file and write it out in reverse order will require enough memory to hold the file. On the other hand, a program with a memory leak will require an unbounded amount of memory to handle an infinite input stream, even though the amount of memory required should be finite.

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

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 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.