How to use Application Verifier to find memory leaks

Question

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).

Answer 1

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.

Answer 2

Application Verifier only catches leaks in DLLs. Try to read the tooltip in the leak checkbox. That's what it says.

Answer 3

Memory Validator from Software Verification will catch memory leaks, and show the complete callstack from the leak's allocation. While it is a commercial product, it has a trial period so programmers can try it and see if it is worth the price to them.

Answer 4

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.

Answer 5

Application Verifier is not the right tool for this job, but I still recommend you have the Application Verifier checks enabled. The valgrind equivalent on Windows is UMDH (User Mode Dump Heap), which is a command line tool.

A former colleague of mine wrote UMDH Gui for at least some usability.

Answer 6

Visual Leak Detector (v2.2) is more useful than the CRT Debug Library because it will show the complete callstack used for memory allocation has led to the leak.

Answer 7

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.