General guidelines to avoid memory leaks in C++ [closed]

Question

What are some general tips to make sure I don't leak memory in C++ programs? How do I figure out who should free memory that has been dynamically allocated?

Celik

Seems pretty constructive to me. – Blackcock

This is constructive. And the answers are supported by facts, expertise, references, etc. And see the number of upvotes/answers..!! – Metalliferous

Answer 1

Instead of managing memory manually, try to use smart pointers where applicable.
Take a look at the Boost lib, TR1, and smart pointers.
Also smart pointers are now a part of C++ standard called C++11.

Spectatress

To compile using g++ one needs to add param: -std=c++0x – Condole

or you can compile with g++ using flag value -std=c++11 – Rescissory

Answer 2

I thoroughly endorse all the advice about RAII and smart pointers, but I'd also like to add a slightly higher-level tip: the easiest memory to manage is the memory you never allocated. Unlike languages like C# and Java, where pretty much everything is a reference, in C++ you should put objects on the stack whenever you can. As I've see several people (including Dr Stroustrup) point out, the main reason why garbage collection has never been popular in C++ is that well-written C++ doesn't produce much garbage in the first place.

Don't write

Object* x = new Object;

or even

shared_ptr<Object> x(new Object);

when you can just write

Object x;

Lorna

I wish I could give this a +10. This is the biggest problem I see with most C++ programmers today, and I assume it is because they learned Java before C++. – Gershwin

Very interesting point – I had wondered why I have C++ memory management issues so much less often than in other languages, but now I see why: it actually allows stuff to go on the stack like in vanilla C. – Odontalgia

So what do you do if you write Object x; and then want to throw x away? say x was created in the main method. – Storax

@user1316459 C++ allows you to create scopes on the fly as well. All you have to do is wrap x's lifetime within braces like so: { Object x; x.DoSomething; }. After the final '}', x's destructor will be called freeing any resources it contains. If x, itself, is the memory to be allocated on the heap, I suggest wrapping it in a unique_ptr so that it is cleaned up easily and appropriately. – Resort

So x is allocated on the stack, does this mean if you pass object x as a parameter then the whole object will be copied? – Aeriela

I wish that all data are in stack. What about sharing data among threads in multi-threaded program? – Stannum

Robert: yes. Ross didn't say "Never write [code containing new]", he said "Don't write [that] when you can just [put it on the stack]". Large objects on the heap will continue to be the right call in most situations, especially for performance-intensive code. – Subaqueous

You just need to be careful about the size you take on the stack. STL containers allocates on the heap but this fact is hidden by the implementation. But if you are about to allocate a huge std::array on the stack, you're gonna have a bad time. But OK, those are corner cases – Volitant

@Robert: No, it doesn't mean that. Even if you allocate x on the stack, you can (and frequently should) write functions that take it by reference. (Of course, you can't return it by reference; but the "return value optimization" means that return by value needn't necessarily involve taking a copy, either.) – Centipoise

Answer 3

Use RAII

• Forget Garbage Collection (Use RAII instead). Note that even the Garbage Collector can leak, too (if you forget to "null" some references in Java/C#), and that Garbage Collector won't help you to dispose of resources (if you have an object which acquired a handle to a file, the file won't be freed automatically when the object will go out of scope if you don't do it manually in Java, or use the "dispose" pattern in C#).
• Forget the "one return per function" rule. This is a good C advice to avoid leaks, but it is outdated in C++ because of its use of exceptions (use RAII instead).
• And while the "Sandwich Pattern" is a good C advice, it is outdated in C++ because of its use of exceptions (use RAII instead).

This post seem to be repetitive, but in C++, the most basic pattern to know is RAII.

Learn to use smart pointers, both from boost, TR1 or even the lowly (but often efficient enough) auto_ptr (but you must know its limitations).

RAII is the basis of both exception safety and resource disposal in C++, and no other pattern (sandwich, etc.) will give you both (and most of the time, it will give you none).

See below a comparison of RAII and non RAII code:

void doSandwich()
{
   T * p = new T() ;
   // do something with p
   delete p ; // leak if the p processing throws or return
}

void doRAIIDynamic()
{
   std::auto_ptr<T> p(new T()) ; // you can use other smart pointers, too
   // do something with p
   // WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}

void doRAIIStatic()
{
   T p ;
   // do something with p
   // WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}

About RAII

To summarize (after the comment from Ogre Psalm33), RAII relies on three concepts:

• Once the object is constructed, it just works! Do acquire resources in the constructor.
• Object destruction is enough! Do free resources in the destructor.
• It's all about scopes! Scoped objects (see doRAIIStatic example above) will be constructed at their declaration, and will be destroyed the moment the execution exits the scope, no matter how the exit (return, break, exception, etc.).

This means that in correct C++ code, most objects won't be constructed with new, and will be declared on the stack instead. And for those constructed using new, all will be somehow scoped (e.g. attached to a smart pointer).

As a developer, this is very powerful indeed as you won't need to care about manual resource handling (as done in C, or for some objects in Java which makes intensive use of try/finally for that case)...

Edit (2012-02-12)

"scoped objects ... will be destructed ... no matter the exit" that's not entirely true. there are ways to cheat RAII. any flavour of terminate() will bypass cleanup. exit(EXIT_SUCCESS) is an oxymoron in this regard.

– wilhelmtell

wilhelmtell is quite right about that: There are exceptional ways to cheat RAII, all leading to the process abrupt stop.

Those are exceptional ways because C++ code is not littered with terminate, exit, etc., or in the case with exceptions, we do want an unhandled exception to crash the process and core dump its memory image as is, and not after cleaning.

But we must still know about those cases because, while they rarely happen, they can still happen.

(who calls terminate or exit in casual C++ code?... I remember having to deal with that problem when playing with GLUT: This library is very C-oriented, going as far as actively designing it to make things difficult for C++ developers like not caring about stack allocated data, or having "interesting" decisions about never returning from their main loop... I won't comment about that).

Scanlan

Must not the T class use RAII to be sure that doRAIIStatic() doesn't leak memory? For example T p(); p.doSandwich(); I don't really know much about this though. – Au

@Ogre Psalm33 : Thanks for the comment. Of course, you're right. I added both links to the RAII Wikipedia page, and a small summary of what is RAII. – Scanlan

How would you implement RAII for a container/collection such as a list or vector? – Zak

@Shiftbit: Three ways, in order of preference: _ _ _ 1. Put real object inside the STL container. _ _ _ 2. Put smart pointers (shared_ptr) of objects inside the STL container. _ _ _ 3. Put raw pointers inside the STL container, but wrap the container to control any access to the data. The wrapper will make sure the destructor will free the allocated objects, and the wrapper accessors will make sure nothing is broken when accessing/modifying the container. – Scanlan

@Scanlan ____4. Use boost pointer containers – Bobbi

Though I suppose thats the same as 3 – Bobbi

When would you doRAIIDynamic vrs doRAIIStatic? Am I right in thinking the static case is allocated on the heap so if the T object is large you would want to use the dynamic version? – Aeriela

@Aeriela : In C++03, you would use doRAIIDynamic in a function that must give the ownership to either a child or parent function (or global scope). Or when you are receiving an interface to a polymorph object through a factory (returning a smart pointer, if it is correctly written). In C++11, this is less the case because you can make your object movable, so giving the ownership of an object declared on the stack is easier... – Scanlan

@Robert: ... Note that declaring an object on the stack doesn't mean that object doesn't use the heap internally (note the double negation... :-) ...). For example, std::string implemented with Small String Optimization will have a buffer "on the stack of the class" for small strings (~15 chars), and will use a pointer to a memory in the heap for larger strings... But from the outside, std::string is still a value type that you declare (usually) on the stack and you use as you would use an integer (as opposed to: as you would use an interface for a polymorph class). – Scanlan

Answer 4

You'll want to look at smart pointers, such as boost's smart pointers.

Instead of

int main()
{ 
    Object* obj = new Object();
    //...
    delete obj;
}

boost::shared_ptr will automatically delete once the reference count is zero:

int main()
{
    boost::shared_ptr<Object> obj(new Object());
    //...
    // destructor destroys when reference count is zero
}

Note my last note, "when reference count is zero, which is the coolest part. So If you have multiple users of your object, you won't have to keep track of whether the object is still in use. Once nobody refers to your shared pointer, it gets destroyed.

This is not a panacea, however. Though you can access the base pointer, you wouldn't want to pass it to a 3rd party API unless you were confident with what it was doing. Lots of times, your "posting" stuff to some other thread for work to be done AFTER the creating scope is finished. This is common with PostThreadMessage in Win32:

void foo()
{
   boost::shared_ptr<Object> obj(new Object()); 

   // Simplified here
   PostThreadMessage(...., (LPARAM)ob.get());
   // Destructor destroys! pointer sent to PostThreadMessage is invalid! Zohnoes!
}

As always, use your thinking cap with any tool...

Sadducee

Answer 5

Read up on RAII and make sure you understand it.

Henigman

Answer 6

Most memory leaks are the result of not being clear about object ownership and lifetime.

The first thing to do is to allocate on the Stack whenever you can. This deals with most of the cases where you need to allocate a single object for some purpose.

If you do need to 'new' an object then most of the time it will have a single obvious owner for the rest of its lifetime. For this situation I tend to use a bunch of collections templates that are designed for 'owning' objects stored in them by pointer. They are implemented with the STL vector and map containers but have some differences:

• These collections can not be copied or assigned to. (once they contain objects.)
• Pointers to objects are inserted into them.
• When the collection is deleted the destructor is first called on all objects in the collection. (I have another version where it asserts if destructed and not empty.)
• Since they store pointers you can also store inherited objects in these containers.

My beaf with STL is that it is so focused on Value objects while in most applications objects are unique entities that do not have meaningful copy semantics required for use in those containers.

Pascia

Answer 7

Bah, you young kids and your new-fangled garbage collectors...

Very strong rules on "ownership" - what object or part of the software has the right to delete the object. Clear comments and wise variable names to make it obvious if a pointer "owns" or is "just look, don't touch". To help decide who owns what, follow as much as possible the "sandwich" pattern within every subroutine or method.

create a thing
use that thing
destroy that thing

Sometimes it's necessary to create and destroy in widely different places; i think hard to avoid that.

In any program requiring complex data structures, i create a strict clear-cut tree of objects containing other objects - using "owner" pointers. This tree models the basic hierarchy of application domain concepts. Example a 3D scene owns objects, lights, textures. At the end of the rendering when the program quits, there's a clear way to destroy everything.

Many other pointers are defined as needed whenever one entity needs access another, to scan over arays or whatever; these are the "just looking". For the 3D scene example - an object uses a texture but does not own; other objects may use that same texture. The destruction of an object does not invoke destruction of any textures.

Yes it's time consuming but that's what i do. I rarely have memory leaks or other problems. But then i work in the limited arena of high-performance scientific, data acquisition and graphics software. I don't often deal transactions like in banking and ecommerce, event-driven GUIs or high networked asynchronous chaos. Maybe the new-fangled ways have an advantage there!

Heterodoxy

I totaly agree. Working in an embedded environment you may also not have the luxury of third party libraries. – Gondolier

I disagree. in the part of "use that thing", if a return or an exception is thrown, then you'll miss the deallocation. As for performance, the std::auto_ptr would cost you nothing. Not that I never code the same way you do. It's just that there is a difference between 100% and 99% secure code. :-) – Scanlan

Answer 8

Great question!

if you are using c++ and you are developing real-time CPU-and-memory boud application (like games) you need to write your own Memory Manager.

I think the better you can do is merge some interesting works of various authors, I can give you some hint:

• Fixed size allocator is heavily discussed, everywhere in the net

• Small Object Allocation was introduced by Alexandrescu in 2001 in his perfect book "Modern c++ design"

• A great advancement (with source code distributed) can be found in an amazing article in Game Programming Gem 7 (2008) named "High Performance Heap allocator" written by Dimitar Lazarov

• A great list of resources can be found in this article

Do not start writing a noob unuseful allocator by yourself... DOCUMENT YOURSELF first.

Leggett

Answer 9

There's already a lot about how to not leak, but if you need a tool to help you track leaks take a look at:

• BoundsChecker under VS
• MMGR C/C++ lib from FluidStudio http://www.paulnettle.com/pub/FluidStudios/MemoryManagers/Fluid_Studios_Memory_Manager.zip (its overrides the allocation methods and creates a report of the allocations, leaks, etc)

Darn

BoundsChecker is 404ing. – Octavo

Answer 10

One technique that has become popular with memory management in C++ is RAII. Basically you use constructors/destructors to handle resource allocation. Of course there are some other obnoxious details in C++ due to exception safety, but the basic idea is pretty simple.

The issue generally comes down to one of ownership. I highly recommend reading the Effective C++ series by Scott Meyers and Modern C++ Design by Andrei Alexandrescu.

Maemaeander

Answer 11

valgrind is a good tool to check your programs memory leakages at runtime, too.

It is available on most flavors of Linux (including Android) and on Darwin.

If you use to write unit tests for your programs, you should get in the habit of systematicaly running valgrind on tests. It will potentially avoid many memory leaks at an early stage. It is also usually easier to pinpoint them in simple tests that in a full software.

Of course this advice stay valid for any other memory check tool.

Houseraising

Answer 12

Share and know memory ownership rules across your project. Using the COM rules makes for the best consistency ([in] parameters are owned by the caller, callee must copy; [out] params are owned by the caller, callee must make a copy if keeping a reference; etc.)

Glazier

Answer 13

User smart pointers everywhere you can! Whole classes of memory leaks just go away.

Openair

Answer 14

Also, don't use manually allocated memory if there's a std library class (e.g. vector). Make sure if you violate that rule that you have a virtual destructor.

Oralee

Answer 15

Tips in order of Importance:

-Tip#1 Always remember to declare your destructors "virtual".

-Tip#2 Use RAII

-Tip#3 Use boost's smartpointers

-Tip#4 Don't write your own buggy Smartpointers, use boost (on a project I'm on right now I can't use boost, and I've suffered having to debug my own smart pointers, I would definately not take the same route again, but then again right now I can't add boost to our dependencies)

-Tip#5 If its some casual/non-performance critical (as in games with thousands of objects) work look at Thorsten Ottosen's boost pointer container

-Tip#6 Find a leak detection header for your platform of choice such as Visual Leak Detection's "vld" header

Pachalic

I may be missing a trick, but how can 'game' and 'non-performance-critical' be in the same sentence? – Zelazny

Games are an example of the critical scenario of course. Might have failed to be clear there – Pachalic

Tip#1 should only be applied if the class has at least one virtual method. I would never impose a useless virtual destructor on a class that isn't meant to serve as a base class in a polymorphic inheritance tree. – Transcription

Answer 16

A frequent source of these bugs is when you have a method that accepts a reference or pointer to an object but leaves ownership unclear. Style and commenting conventions can make this less likely.

Let the case where the function takes ownership of the object be the special case. In all situations where this happens, be sure to write a comment next to the function in the header file indicating this. You should strive to make sure that in most cases the module or class which allocates an object is also responsible for deallocating it.

Using const can help a lot in some cases. If a function will not modify an object, and does not store a reference to it that persists after it returns, accept a const reference. From reading the caller's code it will be obvious that your function has not accepted ownership of the object. You could have had the same function accept a non-const pointer, and the caller may or may not have assumed that the callee accepted ownership, but with a const reference there's no question.

Do not use non-const references in argument lists. It is very unclear when reading the caller code that the callee may have kept a reference to the parameter.

I disagree with the comments recommending reference counted pointers. This usually works fine, but when you have a bug and it doesn't work, especially if your destructor does something non-trivial, such as in a multithreaded program. Definitely try to adjust your design to not need reference counting if it's not too hard.

Asternal

Answer 17

If you can't/don't use a smart pointer for something (although that should be a huge red flag), type in your code with:

allocate
if allocation succeeded:
{ //scope)
     deallocate()
}

That's obvious, but make sure you type it before you type any code in the scope

Glazier

Answer 18

• Try to avoid allocating objects dynamically. As long as classes have appropriate constructors and destructors, use a variable of the class type, not a pointer to it, and you avoid dynamical allocation and deallocation because the compiler will do it for you.
  Actually that's also the mechanism used by "smart pointers" and referred to as RAII by some of the other writers ;-) .
• When you pass objects to other functions, prefer reference parameters over pointers. This avoids some possible errors.
• Declare parameters const, where possible, especially pointers to objects. That way objects can't be freed "accidentially" (except if you cast the const away ;-))).
• Minimize the number of places in the program where you do memory allocation and deallocation. E. g. if you do allocate or free the same type several times, write a function for it (or a factory method ;-)).
  This way you can create debug output (which addresses are allocated and deallocated, ...) easily, if required.
• Use a factory function to allocate objects of several related classes from a single function.
• If your classes have a common base class with a virtual destructor, you can free all of them using the same function (or static method).
• Check your program with tools like purify (unfortunately many $/€/...).

Slagle

Answer 19

valgrind (only avail for *nix platforms) is a very nice memory checker

Antrim

Answer 20

For MSVC only, add the following to the top of each .cpp file:

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

Then, when debugging with VS2003 or greater, you will be told of any leaks when your program exits (it tracks new/delete). It's basic, but it has helped me in the past.

Timi

Answer 21

Others have mentioned ways of avoiding memory leaks in the first place (like smart pointers). But a profiling and memory-analysis tool is often the only way to track down memory problems once you have them.

Valgrind memcheck is an excellent free one.

Marquittamarr

Answer 22

If you are going to manage your memory manually, you have two cases:

1. I created the object (perhaps indirectly, by calling a function that allocates a new object), I use it (or a function I call uses it), then I free it.
2. Somebody gave me the reference, so I should not free it.

If you need to break any of these rules, please document it.

It is all about pointer ownership.

Plunkett

Answer 23

If you can, use boost shared_ptr and standard C++ auto_ptr. Those convey ownership semantics.

When you return an auto_ptr, you are telling the caller that you are giving them ownership of the memory.

When you return a shared_ptr, you are telling the caller that you have a reference to it and they take part of the ownership, but it isn't solely their responsibility.

These semantics also apply to parameters. If the caller passes you an auto_ptr, they are giving you ownership.

Louvain

Answer 24

Manage memory the same way you manage other resources (handles, files, db connections, sockets...). GC would not help you with them either.

Bosomed

Answer 25

One of the only examples about allocating and destroying in different places is thread creation (the parameter you pass). But even in this case is easy. Here is the function/method creating a thread:

struct myparams {
int x;
std::vector<double> z;
}

std::auto_ptr<myparams> param(new myparams(x, ...));
// Release the ownership in case thread creation is successfull
if (0 == pthread_create(&th, NULL, th_func, param.get()) param.release();
...

Here instead the thread function

extern "C" void* th_func(void* p) {
   try {
       std::auto_ptr<myparams> param((myparams*)p);
       ...
   } catch(...) {
   }
   return 0;
}

Pretty easyn isn't it? In case the thread creation fails the resource will be free'd (deleted) by the auto_ptr, otherwise the ownership will be passed to the thread. What if the thread is so fast that after creation it releases the resource before the

param.release();

gets called in the main function/method? Nothing! Because we will 'tell' the auto_ptr to ignore the deallocation. Is C++ memory management easy isn't it? Cheers,

Ema!

Bromleigh

Answer 26

C++ is designed RAII in mind. There is really no better way to manage memory in C++ I think. But be careful not to allocate very big chunks (like buffer objects) on local scope. It can cause stack overflows and, if there is a flaw in bounds checking while using that chunk, you can overwrite other variables or return addresses, which leads to all kinds security holes.

Bertine

Answer 27

We wrap all our allocation functions with a layer that appends a brief string at the front and a sentinel flag at the end. So for example you'd have a call to "myalloc( pszSomeString, iSize, iAlignment ); or new( "description", iSize ) MyObject(); which internally allocates the specified size plus enough space for your header and sentinel. Of course, don't forget to comment this out for non-debug builds! It takes a little more memory to do this but the benefits far outweigh the costs.

This has three benefits - first it allows you to easily and quickly track what code is leaking, by doing quick searches for code allocated in certain 'zones' but not cleaned up when those zones should have freed. It can also be useful to detect when a boundary has been overwritten by checking to ensure all sentinels are intact. This has saved us numerous times when trying to find those well-hidden crashes or array missteps. The third benefit is in tracking the use of memory to see who the big players are - a collation of certain descriptions in a MemDump tells you when 'sound' is taking up way more space than you anticipated, for example.

Jepum

Answer 28

You can intercept the memory allocation functions and see if there are some memory zones not freed upon program exit (though it is not suitable for all the applications).

It can also be done at compile time by replacing operators new and delete and other memory allocation functions.

For example check in this site [Debugging memory allocation in C++] Note: There is a trick for delete operator also something like this:

#define DEBUG_DELETE PrepareDelete(__LINE__,__FILE__); delete
#define delete DEBUG_DELETE

You can store in some variables the name of the file and when the overloaded delete operator will know which was the place it was called from. This way you can have the trace of every delete and malloc from your program. At the end of the memory checking sequence you should be able to report what allocated block of memory was not 'deleted' identifying it by filename and line number which is I guess what you want.

You could also try something like BoundsChecker under Visual Studio which is pretty interesting and easy to use.

Dispensation

Answer 29

Exactly one return from any function. That way you can do deallocation there and never miss it.

It's too easy to make a mistake otherwise:

new a()
if (Bad()) {delete a; return;}
new b()
if (Bad()) {delete a; delete b; return;}
... // etc.

Glazier

Your answer does not match the example code here? I agree with the answer "only one return" but the example code is showing what NOT to do. – Gondolier

C++ RAII's point is exactly to avoid the kind of code you wrote. In C, this is probably the right thing to do. But in C++, your code is flawed. For example: What if new b() throws ? You leak a. – Scanlan