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

[Theodoros V. K. <th...@gm...>]

On Fri, 8 May 2009, Julian Seward wrote:

> 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.

Hmm, after my little leak-hunting expedition this week, I'd settle even 
for a tool that shows where any pointer (not just the last) to a block is 
overwritten. Or maybe the last N pointers that were lost. It would be 
better than nothing...

I actually tried valgrind-3.3.0 and omega. The produced information was 
not really useful, partly because of the structure of the tested program 
and partly because of the fact that any accidentally left-over pointer 
will cover up the leak. I won't even go to the impediments the compiler 
introduces.

I am now thinking that knowing where a particular block was last used 
might be a tad more useful than the location of the actual leak.

> 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.

That was one of my main problems with gcc. For example, even with -O0 
static functions would still disappear, as if they were macros. Several 
variables would only be registers or promptly disappear as well. It was 
surpsingly difficult to figure out in some cases. Perhaps we should 
attempt to convince the GCC people to have an 
--I-mean-it-really-do-not-optimize flag.


Cheers,

Theodoros