On Monday 03 March 2008 12:01, Tom Hughes wrote: > I'm getting thousands of messages along these lines when I turn > on reading of variable info: > > --29598-- warning: addVar: in range 0xFA08 .. 0xFA12 outside segment > 0x36DD005210 .. 0x36DD00FC07 (ignore)
(Background, for the benefit of the archive: the problem occurs when an object is first split into a base object (without Dwarf3 info) and a debuginfo object (with Dwarf3 info), and then the base object is prelinked to some nonzero address, but the debuginfo object is left unchanged.) Well, I have tried to fix this (r7590) but I'd by lying to claim the fix is anything other than an unprincipled kludge, and I can't say I'm happy with the outcome. At least it no longer complains for the test case you sent. But whether it really computes the correct text and data avmas for the affected objects is open to doubt. Is there a way you can test this? I think an adequate test would be to force memcheck to attempt description of an address obtained as follows (force it to describe by free()ing the addr): * a stack-local variable in a thusly-afflicted (debuginfo-split and then prelinked) object * a global var in ditto J ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
