How to find memory leak in a C++ code/project?

Question

I am a C++ programmer on the Windows platform. I am using Visual Studio 2008.

I usually end up in the code with memory leaks.

Normally I find the memory leak by inspecting the code, but it is cumbersome and is not always a good approach.

Since I can't afford a paid memory leak detection tool, I wanted you guys to suggest the best possible ways to avoid memory leaks.

1. I want to the know how the programmer can find memory leaks.
2. Is there any standard or procedure one should follow to ensure there is no memory leak in the program?

Answer 1

If you use gcc, there's gprof available.

I wanted to the know how programmer find memory leak

Some uses tools, some does what you do, could also through peer code review

Is there any standard or procedure one should follow to ensure there is no memory leak in the program

For me: whenever I create dynamically allocated objects, I always put the freeing code after, then fill the code between. This would be OK if you're sure there won't be exceptions in the code between. Otherwise, I make use of try-finally (I don't use C++ frequently).

Answer 2

Neither "new" or "delete" should ever be used in application code. Instead, create a new type that uses the manager/worker idiom, in which the manager class allocates and frees memory and forwards all other operations to the worker object.

Unfortunately this is more work than it should be because C++ doesn't have overloading of "operator .". It is even more work in the presence of polymorphism.

But this is worth the effort because you then don't ever have to worry about memory leaks, which means you don't even have to look for them.

Answer 3

Running "Valgrind" can:

1) Help Identify Memory Leaks - show you how many memory leaks you have, and point out to the lines in the code where the leaked memory was allocated.

2) Point out wrong attempts to free memory (e.g. improper call of "delete")

Instructions for using "Valgrind"

1) Get valgrind here.

1) Compile your code with -g flag

3) In your shell run:

valgrind --leak-check=yes myprog arg1 arg2

Where "myprog" is your compiled program and "arg1", "arg2" your programme's arguments.

4) The result is a list of calls to malloc/new that did not have subsequent calls to free delete.

For example:

==4230==    at 0x1B977DD0: malloc (vg_replace_malloc.c:136)

==4230==    by 0x804990F: main (example.c:6)

Tells you in which line the malloc (that was not freed) was called.

As Pointed out by others, make sure that for every "new"/"malloc" call you have a subsequent "delete"/"free" call.

Answer 4

1. In visual studio, there is a built in detector for memory leak called C Runtime Library. When your program exits after the main function returns, CRT will check the debug heap of your application. if you have any blocks still allocated on the debug heap, then you have memory leak..

2. This forum discusses a few ways to avoid memory leakage in C/C++..

Answer 5

On Windows you can use CRT debug heap.

Is there any standard or procedure one should follow to ensure there is no memory leak in the program.

Yeah, don't use manual memory management (if you ever call delete or delete[] manually, then you're doing it wrong). Use RAII and smart pointers, limit heap allocations to the absolute minimum (most of the time, automatic variables will suffice).

Answer 6

Answering the second part of your question,

Is there any standard or procedure one should follow to ensure there is no memory leak in the program.

Yes, there is. And this is one of the key differences between C and C++.

In C++, you should never call new or delete in your user code. RAII is a very commonly used technique, which pretty much solves the resource management problem. Every resource in your program (a resource is anything that has to be acquired, and then later on, released: file handles, network sockets, database connections, but also plain memory allocations, and in some cases, pairs of API calls (BeginX()/EndX(), LockY(), UnlockY()), should be wrapped in a class, where:

• the constructor acquires the resource (by calling new if the resource is a memroy allocation)
• the destructor releases the resource,
• copying and assignment is either prevented (by making the copy constructor and assignment operators private), or are implemented to work correctly (for example by cloning the underlying resource)

This class is then instantiated locally, on the stack, or as a class member, and not by calling new and storing a pointer.

You often don't need to define these classes yourself. The standard library containers behave in this way as well, so that any object stored into a std::vector gets freed when the vector is destroyed. So again, don't store a pointer into the container (which would require you to call new and delete), but rather the object itself (which gives you memory management for free). Likewise, smart pointer classes can be used to easily wrap objects that just have to be allocated with new, and control their lifetimes.

This means that when the object goes out of scope, it is automatically destroyed, and its resource released and cleaned up.

If you do this consistently throughout your code, you simply won't have any memory leaks. Everything that could get leaked is tied to a destructor which is guaranteed to be called when control leaves the scope in which the object was declared.