Visual Studio 2008 (C++) memory leak detection not showing file/method location - how to get that to work?

Question

I am using the instructions found here to try to find memory leaks in a Win32 application. As described, I put the

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

Lines at the top of a file (the cpp file that contains WINAPI _tWinMain) and then at the exit point of winmain I added

_CrtDumpMemoryLeaks();

Unfortunately I do not see the line numbers/locations for the leaks (but I do get a list of leaks).

I also tried putting

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); 
_CrtSetReportMode ( _CRT_ERROR, _CRTDBG_MODE_DEBUG); 

at the beginning of winmain - and again, no luck.

I find this odd because I usually have had no problems ever finding leaks or having them reported automatically.

This is a huge, old legacy app I am working on for a new employer. In the past I have worked from the standard VS wizard.

Any suggestions on how to get source lines/methods that are causing the leaks? (or at least the lines for the "new" calls?

EDIT:

I also tried visual leak detector - with no success.

Very strange.

EDIT

I tried using the redefinition of new as listed below, however I get errors when boost is compiled in.

Bonaventura

try deleaker. it should help you. – Turncoat

Answer 1

Are you sure the code that's leaking is using the CRT debug allocation routines? That requires using malloc() or new (as opposed to LocalAlloc, GlobalAlloc, some custom block allocator, etc..) and that _DEBUG (I think) must be defined when the CRT headers were included.

In order to get source lines for leaks, you will need to define DEBUG_NEW everywhere the allocations occur. This is because in order to track them, each allocation must be replaced with a call that includes __FILE__ and __LINE__. The standard definition from the wizard looks something like:

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif

This doesn't handle malloc, there's probably a similar incantation for that, if the code you're debugging uses malloc instead of new.

If you're using pre-compiled headers, you can just put this in the precompiled header file and it will affect all the source files in that project.

Perrie

Yep, not using globalalloc. This is very strange to me. I'll try adding the redef of new and see what happens. – Bonaventura

I thought this would solve my problems, but when compiling the boost stuff in the project it chokes. I guess I will have to separate out the boost issues somehow. – Bonaventura

I've run into that as well. Some boost libraries override operator new, and so you have to do the DEBUG_NEW definition after including boost headers, or at least some of them. – Perrie

I was hoping that wasn't the workaround... OK, nothing left to do but roll up the sleeves then. Thanks – Bonaventura

Now I think I know why this was removed... Someone added boost to the project and took out the debug_new I guess. I can't see why else it would not be there. – Bonaventura

Answer 2

Given a list of leaks at the end of the run, something like:

Detected memory leaks!
Dumping objects ->
{12913} normal block at 0x000002BC648BB9D0, 82 bytes long.
 Data: <h t t p : / / a > 68 00 74 00 74 00 70 00 3A 00 2F 00 2F 00 61 00
{12912} normal block at 0x000002BC648B8030, 24 bytes long.
 Data: <0  d      `     > 30 CD 89 64 BC 02 00 00 D8 02 60 E5 F7 7F 00 00
...

It is easy to find where these memory blocks were allocated using _CrtSetBreakAlloc for example for stop when allocation with allocation number 12913 happens one has to put

...
_CrtSetBreakAlloc(12913);
...

somewhere in code before the allocation happens: beginning of the unit tests or main-function are some possible examples. Now, void* __CRTDECL operator new(size_t const size) will throw an exception when block with allocation number 12913 is allocated and from the call-stack in debugger it is easy to find where the allocation did happen.

Genic

sorry for asking after years.. what about if allocation number is not static and gets changed every time when rerun? – Wellordered

@Wellordered Then first you need to eliminate this randomness (I know easier said than done), otherwise you need other tools (like valgrind). – Genic