Filtering Memory Leaks dumped by _CrtDumpMemoryLeaks

Question

I am trying to find leaks in my program, which is a framework based on Ogre3D. I am using the following defines in my code to 'new' anything so that later on any leak can be detected and reported correctly by the program.

#ifdef _DEBUG
#include <crtdbg.h>
    #define MyFW_NEW new(_NORMAL_BLOCK ,__FILE__, __LINE__)
    #define MyFW_DELETE delete
#else
    #define MyFW_NEW new
    #define MyFW_DELETE delete
#endif

This works well, and alerts me to any leaks as long as I 'new' by using MyFW_NEW (if anybody is wondering why I have a define for delete as well, it is merely for completeness and consistency. When I delete something that was newed using MyFW_NEW I want to delete it with MyFW_DELETE).

The problem is that it is detecting leaks within Ogre (whether they are there or it is detecting false leaks is not the concern here) and outputs a myriad of leaks to a file that I have specified and they are so many (mostly repeats) that Visual Studio hangs up for a good 10 minutes, which is unacceptable. The leaks from my framework are lost within the hundred or so leaks from the libraries my framework depends on. Moreover, it does not give me the line number or the file which is responsible for the leak. I know for sure the leaks don't originate from my framework as I have tried commented out everything except a few Ogre's core functions which result in these leaks (output given below).

If I were to assume that these are false leaks (even if they are real leaks, I have to assume this as I cannot change Ogre's source) is there a way I can filter the dump to show leaks from my code only?

Thanks!

EDIT: I forgot to put the output from the leak detection (I am putting only a few as there are a lot)

Detected memory leaks! Dumping objects -> {2123} normal block at 0x036073A8, 32 bytes long. Data: 69 6D 61 67 69 6E 61 74 69 6F 6E 20 74 65 63 68

{355} normal block at 0x008CB2B8, 140 bytes long. Data: < a > 94 0B 61 01 00 00 00 00 CD CD CD CD 00 00 00 00

{351} normal block at 0x008CB058, 12 bytes long. Data: 58 B0 8C 00 58 B0 8C 00 CD CD CD CD

{350} normal block at 0x008C4EB8, 12 bytes long. Data: < N N > B8 4E 8C 00 B8 4E 8C 00 CD CD CD CD

{349} normal block at 0x008CAF78, 160 bytes long. Data: < , d x d > 20 2C 05 64 CD CD CD CD 78 E8 04 64 CD CD CD CD

{348} normal block at 0x008CAF08, 48 bytes long. Data: 4F 67 72 65 2F 53 68 61 64 6F 77 45 78 74 72 75

{347} normal block at 0x008CAE98, 48 bytes long. Data: 4F 67 72 65 2F 53 68 61 64 6F 77 45 78 74 72 75

{346} normal block at 0x008CAE28, 48 bytes long. Data: 4F 67 72 65 2F 53 68 61 64 6F 77 45 78 74 72 75

{345} normal block at 0x008CADB8, 48 bytes long. Data: 4F 67 72 65 2F 53 68 61 64 6F 77 45 78 74 72 75

{344} normal block at 0x008CAD58, 32 bytes long. Data: 4F 67 72 65 2F 53 68 61 64 6F 77 45 78 74 72 75

{343} normal block at 0x008CACF8, 32 bytes long. Data: 4F 67 72 65 2F 53 68 61 64 6F 77 45 78 74 72 75

{342} normal block at 0x008CAC88, 48 bytes long. Data: 4F 67 72 65 2F 53 68 61 64 6F 77 45 78 74 72 75

{341} normal block at 0x008CAC28, 32 bytes long. Data: 4F 67 72 65 2F 53 68 61 64 6F 77 45 78 74 72 75

{340} normal block at 0x008CAB38, 176 bytes long. Data: 73 74 72 75 63 74 20 56 53 5F 4F 55 54 50 55 54

{339} normal block at 0x008CA808, 752 bytes long.

How is it detecting leaks in Ogre3D if (presumably) Ogre3D is never using MyFW_NEW? — acanaday
From what I have read on MSDN, if _DEBUG is defined (in this case, since it is a debug build) then new has been over-written by a couple of defines to make memory leak detection possible (but without line numbers). I might be wrong. — Samaursa

Samaursa Samaursa · Accepted Answer · 2010-08-11T04:51:43

There is no solution to this problem that I could find. If somebody does find the solution, I will change the answer to theirs, otherwise the answer is, don't waste your time, find a good leak detector :)

Filtering Memory Leaks dumped by _CrtDumpMemoryLeaks

2 Answers