How to Ignore False Positive Memory Leaks from _Crtdumpmemoryleaks

ptr_vector - _CrtDumpMemoryLeaks() - memory leaks even though destructor is called

It sure doesn't look like a vector you're leaking. Note that the string is readable, that's at least one hint.

If you can get the number between the curly braces stable ("{173}") then you can get a breakpoint when the memory is allocated. Put this in your main() function:

_crtBreakAlloc = 173;

Use #include <crtdbg.h> if necessary. Repeat for 174 to find the other one.

False memory leaks reported in my MFC app

Just a follow up: I found the real problem, it was relating to the fact that it is a mixed-mode C++/CLI application, and the CLI wasn't allowing the CRT to shut down.

Revised question here:
Mixed-mode C++/CLI app not shutting down CLR correctly

memory leak: unable to break on a memory allocation number

Two suggestions.

Firstly, what gets constructed before main (or equivalent) starts gets destroyed after main finishes. Calling _CrtDumpMemoryLeaks at the end of main can give you false positives. (Or are they false negatives?) Global objects' destructors have yet to run, and atexit callbacks have yet to run, so the leak output will include allocations that have simply yet to be correctly freed.

(I suspect this is why your global objects are appearing to leak. There may well be nothing wrong with the code, and indeed it's quite possibly cleaning itself up properly -- the cleanup code has simply yet to run when _CrtDumpMemoryLeaks is being called.)

What you need to do instead is to direct the runtime library to call _CrtDumpMemoryLeaks for you, right at the end, after all the atexit callbacks and global object destructors have finished. Then you'll only see the genuine leaks. This snippet will do the trick. Stick at at the start of main:

_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)|_CRTDBG_LEAK_CHECK_DF);

Secondly, if the above reveals genuine leaks from stuff that runs before main, you can do a bit of trickery to get some of your own code running pretty much before anything else gets a look in. Then you can set _crtBreakAlloc before any allocations happen. Just pop the following code in a .cpp file of its own:

#include <crtdbg.h>

#ifdef _DEBUG

#pragma warning(disable:4074)//initializers put in compiler reserved initialization area
#pragma init_seg(compiler)//global objects in this file get constructed very early on

struct CrtBreakAllocSetter {
    CrtBreakAllocSetter() {
        _crtBreakAlloc=<allocation number of interest>;
    }
};

CrtBreakAllocSetter g_crtBreakAllocSetter;

#endif//_DEBUG

(I suspect that code in the compiler's init segment may well run before stdin and stdout and the like are initialised, and certainly before any global objects are constructed, so you may have difficulty doing anything more complicated than the above!)

(For what little it's worth, I'm of the opinion these days, and have been for some time now, that allocation before main starts is almost always a bad thing. Makes it hard to clean up after oneself, and difficult to keep track of what's going on. It's certainly convenient, but you always seem to end up paying for it later. That's advice that's much easier to hand out than it is to implement, though, particularly as part of a larger team.)

---

Related Topics