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 ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
