views:

390

answers:

3

I want to find memory leaks in my application using standard utilities. Previously I used my own memory allocator, but other people (yes, you AlienFluid) suggested to use Microsoft's Application Verifier, but I can't seem to get it to report my leaks. I have the following simple application:

#include <iostream>
#include <conio.h>

class X
   {
   public:
      X::X() : m_value(123) {}
   private:
      int m_value;
   };

void main()
{
X *p1 = 0;
X *p2 = 0;
X *p3 = 0;

p1 = new X();
p2 = new X();
p3 = new X();
delete p1;
delete p3;
}

This test clearly contains a memory leak: p2 is new'd but not deleted.

I build the executable using the following command lines:

cl /c /EHsc /Zi /Od /MDd test.cpp
link /debug test.obj

I downloaded Application Verifier (4.0.0665) and enabled all checks.

If I now run my test application I can see a log of it in Application Verifier, but I don't see the memory leak.

Questions:

  • Why doesn't Application Verifier report a leak?
  • Or isn't Application Verifier really intended to find leaks?
  • If it isn't which other tools are available to clearly report leaks at the end of the application (i.e. not by taking regular snapshots and comparing them since this is not possible in an application taking 1GB or more), including the call stack of the place of allocation (so not the simple leak reporting at the end of the CRT)

If I don't find a decent utility, I still have to rely on my own memory manager (which does it perfectly).

+1  A: 

CRT memory leaks detection (without stack trace):

// debug_new.h
#pragma once

#include "crtdbg.h"

#ifdef _DEBUG
#ifndef DEBUG_NEW
#define DEBUG_NEW   new( _NORMAL_BLOCK, __FILE__, __LINE__)
#endif
#endif

All .cpp files:

#include "debug_new.h"

...

// After all other include lines:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif

...

Write this once in the program initialization code:

_CrtSetDbgFlag( _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);

In MFC, all this is already implemented in MFC headers. You only need to ensure, that every cpp file contains these lines:

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

Restrictions: this catches only "new" memory leaks, all leaks, caused by another functions, like malloc, are not caught.

Don't make any allocations inside of .h files - they will be printed without source lines, because DEBUG_NEW is defined after all #include lines.

Alex Farber
This trick doesn't work for malloc/free.One of the include files of the CRT does something similar with MALLOC and FREE (#define free DEBUG_FREE or something like this), and this gives problems with classes that have a method called free (e.g. in Qt).Also, this also writes out the memory leaks, but without call stacks, and I really need the call stacks.
Patrick
A: 

The simplest solution is not to write the leaks or the buffer overflows in the first place - detecting them after the event is really a waste of effort. In my own code, for years I have had zero problems in these areas. Why? Becauase I use the mechanisms that C++ provides to avoid them. For example:

X *p1 = 0;
p1 = new X();

should be:

shared_ptr <X>  p1 = new X();

and you no longer worry about p1 leaking. Better still, don't use dynamic allocation at all:

X x1;

For buffer overflows, always use types like std::string which will grow on input, or if they do not grow will detect the possible overflow and warn you.

I'm not boasting about my prowess in avoiding memory leaks - this stuff really does work, and allows you to get on with the much more difficult task of debugging the business logic of your code.

anon
+1  A: 

I have a feeling that Application Verifier special cases the exit path and doesn't flag these as leaks - after all, the entire process heap is free on process exit.

Try writing another sample where you initialize the same pointer again - basically lose the reference to the previous allocation. That should certainly be flagged. Let me know the results.

Also, AppVerifier (if you have all the options enabled) should also catch buffer overflows, underflows, writing to stack locations marked RO etc.

Alienfluid
BTW, also try the "Global Flags" utility that comes with the Debugging Tools for Windows in the Windows SDK. It has a bunch of options for heap tagging etc. and it might be what you need.
Alienfluid
I tried setting the pointer to 0. Nothing reported in Application Verifier.Tried using GFLAGS to enable all memory-related flags. Nothing reported. It seems that it is simply impossible to get memory leaks at exit (except for the very minimal leak-reporting in the CRT). Seems I have to stick to my own memory manager.
Patrick