Re: [Valgrind-users] Debugging a GC with valgrind

[Dave G. <go...@mc...>]

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.

> It's likely valgrind is being too smart: the code is looking on the "current" stack
> for pointers, it's likely some words were part of a struct with an uninit value,
> this would be harmless. The values are looked up in a "table" (actually
> a JudyArray) to see if they're managed pointers. So it's ok if they're
> uninitialised values.

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

> My problem is that something is overwriting valid storage,
> either a bug in my list handling code or the GC deleting
> reachable objects. I can't tell which. 
> 
> Both pieces of code "seem to work" at least some of the time.
> There's never a problem *unless* the GC is called, but that doesn't
> prove its the GC, its possible the GC is deleting an object and a new
> one is created at the same address (malloc will certainly do this),
> and then the overwrite is causing a problem.

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.

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

-Dave