Detecting memory leaks (VC8)

I did some quick tests and think that this works pretty alright but do some testing yourself as well. I bet there are more situations that will produce false reports than the one I created.

Thanks S_M_A. I was experimenting with your code yesterday and it seems to do exactly what I need. :thumb:

The only bit I didn't understand was this small section:-

Code:

---

  // Uncomment and use callstack to find an allocation without file/line info
  //_crtBreakAlloc = 174;

---

Firstly, I wasn't sure what was the significance of '174'. Secondly, although I did uncomment that line, it didn't seem to make any difference to what I saw in the Output window or the Call Stack window. What should I have been looking for?

John

Ah, should have commented that a bit more.
If you uncomment the

Code:

---

gstringvector.push_back( &gstring );

---

and run it (after you have and change the var names that I forgot to fixup after adding some underscores...) you will get a report that look something like

Code:

---

{170} normal block at 0x003CA3A0, 4 bytes long.
 Data: <    > 00 00 00 00

---

That leak can't be found by pressing F4 (or double-clicking) since it lacks the file/line info. In these situations the only way to find it is to set _crtBreakAlloc to (in this case) 170 and use the callstack to find where it's allocated. The actual number will vary from situation to situation but not from run to run if you don't change anything else. Setting _crtBreakAlloc will slow down the execution speed though and that may cause things to change but hopefully this type of leaks will be rare.

By the way, I must say that the gtk developers show a very un-professional attitude. Every serious developer should strive for having full control over their code.

Edit: I did some more tests and having containers at file scope produce a lot of false reports without file/line info. Using the _CrtSetDbgFlag method does not do that but instead it reports the dll leaks. :(

Quote:

---

Originally Posted by S_M_A

By the way, I must say that the gtk developers show a very un-professional attitude.

---

I must admit that I entirely agree. I tried to persuade them by pointing out the anomalies it creates for gtkmm (the object oriented version of gtk+) - e.g.

Code:

---

#include <gtkmm.h>

int main (int argc, char *argv[])
{
    Gtk::Main *app = new Gtk::Main (&argc, &argv);

    delete app;

    return 0;
}

---

The above code literally produces hundreds of memory leaks although I'm sure that most programmers would assume that Gtk::Main::~Main() would have dutifully cleaned them up. In fact I've realised this morning that it's almost impossible to create and delete any kind of gtkmm object without seeing at least half a dozen leaks. Unfortunately, the official view seems to be that you should only release memory arising from the instantiation of an object. One-off allocations needed for its initial setup / registration etc need not be released.

One of my supporters put it very succinctly:- "releasing many thousands of instantiation pointers then failing to release the relatively small number that are left over at the end is a bit like jumping off a sinking ship, swimming all the way to dry land and then letting yourself drown, just before you reach the shore!"

I did try to find a way of overcoming the false reports but failed. :(

However thinking about it again I would choose to at least in some of the debug runs use the _CrtSetDbgFlag method. After all, the gtk leaks will be without file/line info so F4 will skip them and just show those in your code.

It's not exactly the perfect streamlined solution but both methods have their pros and cons so what to do...