CODEWITHSUNDEEP
c++visual-studio-2008memory-leaks
Tim
Tim

Reputation: 20360

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

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.

Upvotes: 10

Views: 10779

Answers (2)

ead
ead

Reputation: 34347

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.

Upvotes: 1

Tim Sylvester
Tim Sylvester

Reputation: 23148

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.

Upvotes: 6

Related Questions