Re: [Valgrind-users] "Potentially" lost memory

[Philippe W. <phi...@sk...>]

On Thu, 2013-03-14 at 14:18 -0700, Patrick J. LoPresti wrote:
> On Thu, Mar 14, 2013 at 1:58 PM, Philippe Waroquiers
> <phi...@sk...> wrote:
> > On Thu, 2013-03-14 at 19:21 +0000, Phil Longstaff wrote:
> >> How hard would it be for memcheck to not report a block as being
> >> potentially lost if the internal pointer could be a pointer to a base
> >> class?  Is there sufficient info in the debug information?
> > No, I do not think so.
> 
> Probably correct in general. But...
> 
> For polymorphic C++ classes -- presumably a common case when you have
> a pointer to an internal base class -- dynamic_cast<Derived>() has to
> work somehow. So I would imagine Valgrind could use the same RTTI
> mechanism. In theory.

The problem is that Valgrind only has a piece of memory.
It does not know if this piece of memory is
   a dynamically allocated C++ object
or a dynamically allocated string
or a dynamically allocated array of integers
Assuming this piece of memory is a C++ object, and starting
RTTI on that implies to heuristically guess if the memory piece
looks like a C++ object. Valgrind cannot be sure of that.

In other words, Valgrind will do RTTI by doing an "unchecked cast"
of any piece of memory to which it finds an interior pointer.

IIUC, DrMemory leak checker uses an heuristic by assuming
the V-table pointer is located at the beginning of the piece
of memory, and "confirming" this is a V-table pointer by looking
if this V-table pointer points to an array of words
which are themselves pointing into the text segment of
of the application.

I do not have a good knowledge of C++ and multiple inheritance
v-tables and similar, so I am not sure I properly understand
all the above.

Such an heuristic might create false negative. There are however
already false negative (as e.g. any integer might look like
a "start" pointer). E.g. on a 32 bit application which allocates
a lot of memory, filled in with a lot of different integers,
there is a significant probability to have false negative.

Philippe