|
From: Simon U. <sim...@or...> - 2011-04-16 01:00:33
|
Hi!
First of all, let me note that this is not about valgrind working
incorrectly, but rather about practices and/or what can be done in the
following situation.
So the problem is that we're getting lots of "potential memory leak"
errors reported in the situations where in fact the memory is still
reachable. The particular situations include:
1) Virtual inheritance, where the stored pointer refers to a virtual base
2) Multiple inheritance, where the stored pointer refers to one of the
secondary bases
3) Intrusive containers, e.g. a list implemented so that the "next"
pointer points inside of the adjacent member instead of pointing to the
beginning of the allocated memory block
The following code demonstrates the issue for the case (1):
----------
struct VBase { int data; virtual ~VBase() {}; };
struct Derived : virtual public VBase {};
static VBase * holder = new Derived;
int main() { return 0; }
----------
Naturally, valgrind reports there is "possibly lost" memory:
----------
> ==24706== LEAK SUMMARY:
> ==24706== definitely lost: 0 bytes in 0 blocks.
> ==24706== possibly lost: 24 bytes in 1 blocks.
> ==24706== still reachable: 0 bytes in 0 blocks.
----------
Our tentative goal is to keep "definitely lost" and "possibly lost"
numbers to zero (only allowing "still reachable"). There is however only
so much that we can do with the code-base to "fix" it.
Essentially, two "workarounds" have been pronounced so far:
A) Disregard the "definitely lost" and only look at "definitely lost".
The drawback is that we're loosing the "definitely lost" analysis it for
all kinds of allocations.
B) Suppress the errors for the known "misbehaving" structures. The
drawback is that we're completely loosing leak detection for those
structures. I.e. valgrind won't report "definitely lost" for them any more.
C) Enhance valgrind suppression rules to allow suppressing of "potential
memory leaks" only. Is it worth? Is it tough?
Are we missing something obvious? Are there better workarounds?
Feedback is welcome!
Thanks,
Simon
|