Help! I Have a Memory Leak

来源:互联网 发布:ubuntu mate更改分辨率 编辑:程序博客网 时间:2024/05/19 14:40

 

 
Recently i had a project which had some of the worst memory leaks in C++ i’ve ever had to deal with. It had just about every memory leak problem you could think of, all of which could have been solved with a little bit of planning.

Using tools such as Valgrind or Instruments surely helps, but they can only help you so much.

So if you have a nightmarish C++ project with memory leaks, heres a few ways in which you can solve them.

Stage 1: Forgetfulness
We start off with a simple case: when you make an object but never delete it. e.g.:

  Object *foo = new Object(); // foo never deleted

Which can be solved by:

  delete foo; // <<< delete the object

Stage 2: Garbage Collection
Sometimes you have a pointer to an object which is re-assigned at one point, but the old object is never deleted.

Which can be solved by deleting the object before re-assigning:

Stage 3: Destructors
Some people assume if you make a couple of classes like this:

If you destroy an instance of Woo both ~Woo and ~Foo will be called. Only it wont: only~Woo will be called. Anything you free in~Foo will never be freed.

So if you want ~Foo to be called too, the destructor for Foo needs to be virtual, i.e.:

  class Foo
  {
    Foo();
    virtual ~Foo(); // <<<
  };

Stage 4: Spaghetti
Things start getting complicated when you have objects which can be referenced by multiple objects. For example:

  Now when do we delete foo? If we make child1 or child2 delete it, we’ll probably get a crash when we deletefoo twice. If we delete it elsewhere, how do we knowchild1 or child2 aren’t still using it?

One possible solution is to use a reference counting system like in Objective C, so when we reach 0 we delete the object:

Beware however that when you get a circular reference your objects may never be released using this method.

Stage 5: Runaway Spaghetti
Even if you have a reference counting system, you might encounter situations where you release or retain objects too much. Typically memory leak tools only tell you where objects were allocated, not who the retain/release culprit is.

One way of solving this is to keep track of where you retain and release objects

  Then you can simply examine your logs and spot the problematic line of code for that extra release or retain.

Final boss
Of course once you have solved all of your leaks, you might find you bump into the arch nemesis: Memory Corruption. Specifically, this:

 What is wrong with this? Well say we have some code like this….

 Then think may never be called, since mNextThink is never initialized, so its value will be undefined. It could be 0, it could be -10000. Who knows. The solution is simple:

 

 

With all of your memory leaks solved, you should now be able to sleep better.