Re: [Valgrind-users] Memcheck and lost pointer tracking

[Julian S. <js...@ac...>]

On Friday 08 May 2009, Theodoros V. Kalamatianos wrote:
> On Fri, 8 May 2009, Nicholas Nethercote wrote:
> > This paper is related too:
> >
> >    author      = {Jonas Maebe and Michiel Ronsse and Koen De Bosschere},
> >    title       = {Precise detection of memory leaks},
> >    booktitle   = {Proceedings of the Second International Workshop on
> > Dynamic Analysis (WODA 2004)},
> >    pages       = {},
> >    address     = {Edinburgh, Scotland},
> >    month       = may,
> >    year        = 2004,
>
> I'll have a look at it.
>
> > In general, what you are proposing is possible, but it's not easy, is
> > really slow and would be lots of extra code in Memcheck.

I'm not convinced it's really possible.  The basic problem is that,
due to how the compiler generates code, the last pointer to a block
can be overwritten at some place which is arbitrarily far away (but
in the same procedure) from where it is overwritten in the source,
thus leading to a nonsensical error report.

How can this happen?  Imagine a procedure P which is quite large, and
a block B.  Relatively early in P, there is high register pressure and
so a copy of the pointer to B written to a spill slot.  A bit further
along, the last pointer to B is overwritten in the source level, but
the tool makes no comment because there's a copy in the spill slot.

Then further along in P, a different value is written into the spill slot.
At this point, the tool complains, but the source location is completely
wrong.  What's more, because it's a spill store, there may not even be
any source level store for the user to see, at the stated source line.

I would be interested to hear if the authors of the abovementioned paper
managed to solve this problem.

If you can devise a scheme that works reliably in the presence of spilling
(viz, stack loads/stores introduced invisibly by the compiler) then you might
be heading in a good direction.

J