On 20/01/2011, at 2:39 AM, Dave Goodell wrote:
> On Jan 18, 2011, at 10:56 PM CST, john skaller wrote:
>
>> On 19/01/2011, at 5:58 AM, Dave Goodell wrote:
>>
>>> 2) Tracking down "uninitialized value" warnings is much easier if you use
>>> the "--track-origins=yes" option to Valgrind.
>>
>> Also done. Told me the function "making" the original uninit value, but I
>> already
>> knew that anyhow. I needed to know which variable.
>
> If it's not obvious from the line of code that is marked as the origin, then
> sometimes "--read-var-info=yes" will also help. It tells valgrind to read
> the debug info in the binary and attempt to give variable names for global
> and stack variables.
Yeah, I have done that too ;( Didn't help. On OSX so I also had to use
-dsymthing flag.
>
> Using Valgrind with a custom memory allocator is a bit of a special case. It
> usually requires work with client requests to help Valgrind know that various
> accesses are actually safe (or unsafe).
Actually, the allocator is malloc/free. The GC just decides when to do the free.
I got rid of the uninitialised values diagnostic, unfortunately globally.
I could rewrite the GC so that the stack scan is in a separate subroutine,
and then just exclude that using Valgrinds nice suppression mechanism.
> You could try using the various MEMPOOL client requests so that Valgrind
> might also be able to report errors in terms of a particular object's
> allocation stack trace. But I'm not sure I understand your situation 100%,
> so there's no guarantee that it will help.
Not using a pool: standard malloc/free. As above, it's just that the GC scans
the stack (and registered roots) and chases
down pointers to find what's reachable, and free()s everything that isn't.
Naturally this is extremely sensitive to knowing where pointers are in objects,
and making sure the whole stack (including any registers) are scanned.
I use setjmp() to push registers on the stack (same as Boehm collector).
The stack pointer is out by one word (as Valgrind showed) because I use
void *get_stack_pointer() { void *x = (void*)&x; return x; }
to get the stack pointer (I need to add one word on to account for the PC)
however the
extra word in the "hot zone" doesn't matter (the scan is conservative so at
worst some
memory is leaked).
>
>>> The key bit is that Valgrind is marking the whole red zone as "undefined"
>>> at function entrance/exit, so only areas that are actually written during
>>> that function are potentially going to be marked as "defined".
>>
>> Yeah, I see, so actually the "red zone" is only safe to use within a
>> function as "scratch" area.
>
> Sure, but it makes sense that a conservative collector like yours must scan
> the whole red zone. You're just doing something unconventional from
> Valgrind's point of view, so you need to tell it that you Know What You Are
> Doing.
Well that's interesting. It isn't scanning the whole red zone. Maybe it should!!
See above, how I get the low address bound. Still, if the redzone is only
"active" inside a
function and never across a function call, there's no need to scan it (since,
say,
the get_stack_pointer routine is a function call it should invalidate the
red-zone,
if I understand the comments you posted in your last email).
--
john skaller
skal...@users.sourceforge.net
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
