Dealing with incorrect memory leak reports on Windows

Question

I'm writing some Windows software and when it terminates, I'm getting a lot of incorrect memory leak messages:

Detected memory leaks!
Dumping objects ->
{29745} normal block at 0x02938E38, 36 bytes long.
 Data: <, E             > 2C 0B 45 10 00 00 00 00 01 00 00 00 01 CD CD CD 
{29732} normal block at 0x02938C08, 500 bytes long.
 Data: <X)A         `  @> 58 29 41 10 00 00 00 00 01 00 00 00 60 93 0B 40 
{29721} normal block at 0x028DA8A0, 84 bytes long.
 Data: < 1D         0 %i> C8 31 44 10 00 00 00 00 01 00 00 00 30 85 25 69

I'm certain these are false positives. Do you have any suggestions on dealing with this? As the software grows, there are likely to be some actual leaks and finding them will be difficult, to say the least.

Edit:
I should have mentioned that I'm using a library called OpenSceneGraph. It makes heavy use internally of reference counted smart pointers. All of these leaks are instances that I new then pass into the library which promptly wraps it in a ref_ptr<>. I know the instances aren't leaking because I've added fprintf to the destructor and I do see the message when the smart pointer goes out of scope. Microsoft had a problem like this a while ago with the standard library and I'm wondering if I'm seeing something similar here? Apparently the bug was related to some _CRT_BLOCKS getting tagged as _NORMAL_BLOCKS.

Edit 2:

I figured out what's going on. The code that dumps the memory leak information happens before all the static data goes out of scope. In one case an internal object is constructed via the prototype pattern and the prototype object is static and so isn't destroyed until the atexit machinery kicks in. So, nothing is really leaking. It's just that the dump is happening before the app tear-down happens.

Answer 1

I find it highly unlikely that those are false positives. A they say in the Pragmatic Programmer, SELECT isn't broken.

Answer 2

When I've gotten that problem before (something that seems to be deleted is showing up as leaked), it's usually because I've forgotten or didn't account for a pointer assignment replacing the one that I new'd.

Then it "seems" to delete just fine, while the original new'd object leaks away.

Answer 3

No, you have leaked. The size of the objects should be a pretty good indicator. These appear to be objects you newed - the various bits left at 0xCD are indicative of bytes provided by the debug version of the memory allocator.

When faced with issues like this, I always ask myself: what's more likely, that the compiler/IDE developed by some of the smartest people on earth is right, or that I am ?

Answer 4

which compiler?

Get another profiling/leak detection tool as well. (Boundschecker, etc)

The false positives I've gotten in the past never obstructed me from finding "real" leaks.

I don't agree with the others who say that you are wrong about false positives - But do double check - check all your "new"s and trace the application logic to convince yourself that these are false.

You can also add guards or tags or memory signatures in your objects so you can ensure that they aren't things you created.

Not sure what to tell you about 3rd party stuff. I'd contact the 3rd party software company and ask them if they are aware of any issues - false positives or otherwise.

Answer 5

I would also say that is very likely you have real leeks (they might also be in some 3rd party code you are using).

But there is a way to find exactly what allocation is not released. See here: http://msdn.microsoft.com/en-us/library/w2fhc9a3(VS.71).aspx

(Of course, for other versions of VS you must change the dll name in this:

{,,msvcr71d.dll}_crtBreakAlloc

to the proper version (msvcr90d.dll = VS 2008, msvcr80d.dll = VS 2005, msvcr71d.dll = VS 2003, msvcr70d.dll = VS 2002)