10

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.

Tim
  • 20,184
  • 24
  • 117
  • 214

2 Answers2

6

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Tim Sylvester
  • 22,897
  • 2
  • 80
  • 94
  • Yep, not using globalalloc. This is very strange to me. I'll try adding the redef of new and see what happens. – Tim Oct 14 '09 at 18:13
  • 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. – Tim Oct 14 '09 at 18:36
  • 6
    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. – Tim Sylvester Oct 14 '09 at 18:45
  • I was hoping that wasn't the workaround... OK, nothing left to do but roll up the sleeves then. Thanks – Tim Oct 14 '09 at 18:55
  • 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. – Tim Oct 14 '09 at 19:02
1

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.

ead
  • 32,758
  • 6
  • 90
  • 153
  • sorry for asking after years.. what about if allocation number is not static and gets changed every time when rerun? – Zrn-dev Nov 28 '22 at 07:42
  • @Zrn-dev Then first you need to eliminate this randomness (I know easier said than done), otherwise you need other tools (like valgrind). – ead Nov 29 '22 at 06:58