CODEWITHSUNDEEP
memory-leaks
criddell
criddell

Reputation: 14599

Dealing with incorrect memory leak reports on Windows

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.

Upvotes: 2

Views: 1632

Answers (5)

DAmann
DAmann

Reputation: 194

VS gives leaked memory reports for memory allocated as static in a .dll (that does not use MFC), as the report is (for some reason) generated before the .dlls are dropped (and they will be correctly de-allocated when the dlls are unloaded). Hence the false positive.

Upvotes: 1

Mihai Nita
Mihai Nita

Reputation: 5787

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)

Upvotes: 2

Tim
Tim

Reputation: 20360

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.

Upvotes: 2

Craig H
Craig H

Reputation: 7989

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

Upvotes: 2

simtel
simtel

Reputation:

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.

Upvotes: 1

Related Questions