Is there a simple example of false-positive valgrind "possibly lost" report?

Question

From reading about the valgrind memory leak report of "possibly lost", I had understood that there is a very small chance that this kind of report will be a false-positive report. What I could not understand how this can occur on a normal circumstances without doing something very forced to the code.

So for understanding this option, I am asking is there a simple example of false-positive valgrind "possibly lost" memory leak report?

Zebulun

Answer 1

Here is an example of a repeatable "possibly lost":

class A {
    int x;
};
class B {
    int y;
};
class C : public A, public B {
    int z;
};

int main() {
    static B* notLost = new C();    //The upcast will change the pointer to point 4 bytes into the object, because that is the offset of the B subobject within the C object.
    //Valgrind thinks, the new object may be possibly unreachable.
    //But I can still do this:
//  delete (C*)notLost; //The downcast undoes the pointer modification by the upcast.
}

Hassle

Is there also an good example for the case of "possibly lost" report, because I did not understand how there could be a false-positive report in that case? – Zebulun

@user2579277: Sorry, I could not respond sooner, I have now added a more direct example. – Hassle

I am sorry but your new example for possibly lost does not show as problem in an valgrind report. And for the second example, asprint allocate memory in it's core so the valgrind report is not false positive. – Zebulun

@user2579277: I've just verified the "possibly lost" example, you get the false positive if you comment out the delete statement, maybe I was not clear enough on that. The other example is indeed slightly wrong in that it turns up as "still reachable" instead of "lost", but that's the classic false positive with valgrind. I do not think it's possible to construct a sensible false positive for "lost", though. – Hassle

@PaulFloyd If you have problems compiling the example code, that's a bug that needs to be fixed. Simply deleting it entirely from an answer without even talking about it with the OP first in the comments first, is not exactly nice. Anyway, what was your actual problem with the code? I'm pretty certain we can fix it if we work together... – Hassle

Answer 2

There seems to be a big problem of perception as to what a "possible leak" means.

Firstly, a leak is when memory is allocated but not deallocated. A false positive would be if Memcheck reports a leak when there isn't one. That could happen if you provide a replacement for malloc but then use a non-standard name (say dealloc) for your deallocation function rather than free.

Secondly, there is the categorization of the leak. For each leak that Memcheck finds it will scan through memory and registers trying to find pointers to that memory block.

• If it finds no pointers that is a definite leak
• If it finds pointers in memory that is no longer accessible (deallocated) then that is an indirect leak
• If it finds pointers to the start of the memory block then that is reachable.
• If it finds pointers to somewhere inside the block other than the start then that's a possible leak. This could just be random junk that happens to be the same as the pointer. And it could be something like a redzone, size:data or the base-to-derived pointer in cmaster's example. It's difficult for Memcheck to tell whether it is accidental or not (there are a few heuristics). Since it can't tell it marks these as potential leaks.

Spice