What types of false positive memory leaks can you report?
If you are looking for memory leaks using some kind of "tool" like WinDbg, GlowCode, or even the Visual C ++ Integrated Leak Reporter, what types of false positives can you report?
In fact, GlowCode warns you about false positives. More false positives may appear depending on the type of scan you run.
With this question, I'm trying to figure out, for example, how the GlowCode scanner compares to WinDbg !heap -l
...
I would appreciate any hint you can provide!
UPDATE: if you could provide a real example in C ++ (or your preferred language) that would help a lot.
source to share
The general approach of memory debuggers is to report all allocated memory when the program exits. This memory might be leaking, but it might just be memory that is allocated throughout the life of the application and is never explicitly released (in itself a programming problem).
Other tools (such as static analyzers) try to match alloc / release calls or certain programming patterns. For example, the MS pre-tool will warn you if you allocate memory and call functions that might throw exceptions without a try block. One case where this would be a false positive is where the selected objects are automatically deleted when their parent is destroyed.
source to share
The leak detector reports two types of memory:
-
which is no longer available (i.e. there is no way to get a pointer to them from a global variable). There may be a false value here (in the sense that memory is still available) if you are playing tricks to hide the pointer to the value. Some of them correspond, some work in practice, but not. They are often questionable, but they can come in handy when working with limited memory. I haven't used them since my days on embedded 8-bit systems. They are usually rare in the code base.
-
memory that is still available at the end of the program but is not freed. This kind can be called "false positive". This usage is style specific; you can question the validity of the practice of not deleting objects on program exit, as you can question the usefulness of doing unobservable work, as well as unobservable work, since execution time is ignored. Note that sometimes this is done on purpose, so that the object can be used in static destructors called upon exit.
source to share
Suppose you have allocated memory at address A and at address B and stored the values to the appropriate pointers. Then you replace the values of A and B with (A + B) and (AB) respectively.
And how is the world supposed to check that the memory is still available? You can indeed restore the original pointer values, and perhaps you are actually doing somewhere. But how can you guess? And if you've mangled the values with trigonometric functions or say RSA? :)
One more thing. You say that more false positives means a worse tool. But generally, as the number of false positives increases, the number of false negatives decreases. He likes to become a more suspicious detective in order to catch the elusive criminal, but at the same time steal more innocent people.
source to share