[Gc] Valgrind/gc: failure in GC_malloc ?

jim marshall jim.marshall at wbemsolutions.com
Wed Feb 7 07:42:55 PST 2007

 I would love to get my app running on Valgrind using the GC. Would you 
mind explaining in a bit more detail what has to be done? Do we need to 
modify GC source code or is this something we can do in our application?


Paolo Molaro wrote:
> On 01/20/07 Marnix Klooster wrote:
>> Been there, done that, asked the same question in the same place, got a 
>> --how shall I put it-- very clear answer that no-one in their right mind 
>> would want to use valgrind+gc since gc has its own nice memory usage 
>> tracing options thankyouverymuch.
> The built-in memory debugging features have only limited use: valgrind
> is much more powerful (and of course slower, but it's invaluable).
> I'm sorry if I didn't post my solution sooner, I meant
> to but forgot to post it.
> The interaction issue between valgrind and the GC is as follows:
> the GC gets the main stack boundaries from /proc (GC_stackbottom),
> but it assumes it is initialized in the main thread. Now, when running
> under valgrind (or when the GC is loaded from a shared module or
> otherwise initialized from a non-main thread) the boundary info is
> incorrect and what usually happens is that when tracing the stack
> the GC will hit some unmapped page (or the stack sentinel page)
> between the thread stack and the main thread stack.
>  GC_stackbottom ->      |
>                         | main() thread stack (or valgrind stack)
>                         |
>                         # sentinel page
>  correct stackbottom -> |
>                         | GC_init () stack
>                         |
>                         | GC_collect () stack frame
> What we did in mono is to explicitly set GC_stackbottom in the
> initialization thread (which can be the main thread too from the point
> of view of an app running in valgrind) with one of the following,
> depending on the architecture:
> 1) pthread_getattr_np/pthread_attr_getstack
> 2) pthread_get_stackaddr_np
> 3) guessing that we are close to the top of the stack and rounding up
> Note that pthread_attr_getstack() can fail without error and return a
> NULL stack start.
> This hasn't been submitted for inclusion because it is sort of an hack.
> I guess changing the GC method of checking GC_stackbottom to always use
> pthread_getattr_np/pthread_attr_getstack or pthread_get_stackaddr_np
> if they are available and only if not using the other methods makes
> sense. Instead of 3 one could try to parse the equivalent of
> /proc/self/maps, but I guess that the architecture that provide the maps
> feature already provides the pthread calls, too.
> lupus

Jim Marshall
Sr. Staff Engineer
WBEM Solutions, Inc.

More information about the Gc mailing list