What types of false positive memory leaks can be reported?

Question

When you look for memory leaks using some kind of "tool" like, for example, WinDbg, GlowCode or even the integrated Visual C++ leak reporter, what types of false positives can be reported?

In fact, GlowCode warns you against false positives. Depending on the type of scan that you run, more false positives can appear.

With this question I'm trying to figure out things like how GlowCode scanner compares to WinDbg's !heap -l...

I'll appreciate any hint you can provide!

UPDATE: If you could give some real example in C++ (or your preferred language) that would help a lot.

Answer 1

The general approach of memory debuggers is to report all allocated memory at program exit. This memory could be leaked, but it could be just memory that is allocated for the entire lifetime of the application and never released explicitly (a questionable programming practice in itself).

Other tools (static analyzers for example) try to match alloc/release calls or certain programming patterns. The MS prefast tool for example will warn you if you allocate memory and call functions that can throw exceptions without a try block. One case where this would be a false positive is where the allocated objects are deleted automatically when their parent is destroyed.

Answer 2

There are two kinds of memory reported by leak detector:

• memory which is no more reachable (i.e. there is no way to get a pointer to them from global variable). There can be false positive here (in the sense that the memory is still in fact reachable) if you play tricks to hide the value pointer. Some of those are conforming, some works in practice but aren't. They often are of dubious nature but can come handy when working in memory tight situation. I haven't used them since my days in embedded 8 bits systems. Those usually are rare in code base.

• memory which is still reachable at the end of the program but has not be freed. This kind can be named "false positive". This usage is a matter of style; one may question the soundness of the practice of not deleting objects when quitting the program as one may question the utility of making unobservable work, well unobservable as far as runtime is ignored. Note that sometimes, it is done purposely, so that the object can be used in static destructors which are called when the program exits.

Answer 3

Assume you have allocated memory at address A and at address B and saved the values to corresponding pointers. Then you replace A and B values with (A+B) and (A-B) respectively.

And how in the world should the checker guess that the memory is still reachable? You really can restore original pointer values, and maybe you somewhere really do. But how should it guess that? And if you mangled the values with trigonometrical functions or, say, RSA? :)

One more thing. You sound like that greater amount of false positives means worse tool. But, generally, when the number of false positives grows, the number of false negatives decreases. It's like becoming a more suspicious detective to catch an elusive criminal, but at the same time hijack greater number of innocent people.