Detecting memory leaks (VC8)

[John E]

When I was using VC6 I could run a program in the debugger and, on closing the program down, VC6's debug output window would flag up a message if the program had leaked any memory. I don't seem to see this any more with VC8. Is there a setting somewhere that I need to enable?

[cilu]

I don't know about any option for that, but if exists it is definitely enabled by default. I never had to check anything for that and it works in all the versions I'm using (2005, 2008, 2010). Maybe you just don't have memory leaks.

[John E]

#include "stdafx.h"
#include <stdio.h>
#include <conio.h>

int _tmain(int argc, _TCHAR* argv[])
{
	int *p = new int[20];
	printf("Press ENTER to quit");
	getchar();

	return 0;
}

Hmmm.... am I doing something silly? The above console app should flag up a memory leak in the output window after completion, right?

[ovidiucucu]

right?

Nope.

[itsmeandnobodyelse]

The memory leaks were reported when you use the macro DEBUG_NEW in your sources which actually provides a different operator new and operator delete where all allocations and deallocations were watched.

[ovidiucucu]

Basically, the memory leaks are reported in debug mode when call _CrtDumpMemoryLeaks.

[Lindley]

http://msdn.microsoft.com/en-us/libr...=VS.90%29.aspx

[John E]

http://msdn.microsoft.com/en-us/libr...=VS.90%29.aspx

Interesting.... I've never #included crtdbg.h in my life but this always worked before. Having said that, my old VC6 programs invariably used MFC which I haven't been using since moving to VC8. Maybe that's how crtdbg.h was getting included. Thanks all, for the info.

[ovidiucucu]

MFC framework and MFC wizards take care of many things which usually we don't even think about...

[John E]

http://msdn.microsoft.com/en-us/libr...=VS.90%29.aspx

Just found some time to try this and yes, basically it works. According to that article I should see some output looking like this:-

Detected memory leaks!
Dumping objects ->
C:\PROGRAM FILES\VISUAL STUDIO\MyProjects\leaktest\leaktest.cpp(20) : {18}
normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

and indeed I do see such output as long as I allocated my memory using malloc() - but in my original example (using new) I see this:-

Detected memory leaks!
Dumping objects ->
e:\program files\microsoft visual studio 8\vc\include\crtdbg.h(1150) : {90} normal block at 0x00351A60, 80 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

Obviously, that's showing me the location of the debug new operator in crtdbg.h, rather than the position in my source file where new got used. Is there a way to fix this?

[MrViggy]

Just use crtBreakAlloc.

Viggy

[S_M_A]

If you use

#ifdef _DEBUG
   #define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
   #define DEBUG_CLIENTBLOCK
#endif

in your 'general header include' and

#ifdef _DEBUG
  #define new DEBUG_CLIENTBLOCK
#endif

in all your ccp-files

In the code I use this I also do

#if defined(_DEBUG)
  int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
  tmpFlag    |= _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF;  // Check heap alloc and dump mem leaks at exit
  _CrtSetDbgFlag( tmpFlag );
  //_crtBreakAlloc = 58652; // in case something very bad happens
  assert( !errno );
#endif

as the very first thing in main

[John E]

Thanks guys, I'll try your suggestions later today. MFC has obviously been handling this "under the hood" for many years without me realising the intricacies. The particular project that I'll be building will be using GTK+ though, rather than MFC and I can already see that detecting memory leaks will be considerably more complicated than I thought. Here's a modified version of the simple console app that I used before:-

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#include "stdafx.h"
#include <stdio.h>
#include <conio.h>
#include <string>
#include "..\..\..\+GTK-SOURCES\gnu-mm\libs\glibmm2\glibmm\ustring.h"

const std::string    strTest1 = "A test string";
const Glib::ustring  strTest2 = "Another test string";

int _tmain(int argc, _TCHAR* argv[])
{
	int *p = (int*)malloc(20 * sizeof(int));

	printf("Press ENTER to quit");
	getchar();

	_CrtDumpMemoryLeaks();
	return 0;
}

I haven't yet added those new features you guys mentioned but note the global objects strTest1 and strTest2. _CrtDumpMemoryLeaks() flags up a memory leak from strTest2 (a Glib::ustring) presumably because global objects haven't yet released their memory by the time I called _CrtDumpMemoryLeaks().

What's interesting is that no leak got detected from strTest1 (which was a std::string). Things get really interesting though if I build a simple MFC app instead of my console app. In that case, the leak from malloc() gets (correctly) detected but no leaks get detected from either of the global objects.

Clearly MFC is pretty clever about where exactly it calls _CrtDumpMemoryLeaks() and I guess I've a lot more to learn about using this feature properly. Maybe this is a good reason to go back to MFC....

No, only joking. This is a cross-platform app, so MFC is out of the question.

[itsmeandnobodyelse]

We, the MFC fans, were all the years looking for someone who makes MFC a cross-platform library

[Lindley]

Personally I find it rather difficult to determine exactly which gtk+ objects need explicit deletion and which don't, since gtk+ uses some kind of reference counting which isn't documented all that well.

This might be one good reason to choose gtkmm instead; C++ libraries typically do memory stuff a bit more automatically. I don't know gtkmm well enough to say how much they've cleaned things up though.