[Gc] GC_init from non-main thread fails with segfault
hans.boehm at hp.com
Tue Jan 10 11:11:43 PST 2006
The GC should be intercepting all calls to pthread_create. Normally
this should be done by defining GC_THREADS and including gc.h in files
that make any pthread calls (other than simple synchronization calls
The theory is that since pthread_create calls should really be turned
into GC_pthread_create calls, and GC_pthread_create should call
GC_init(), the first GC_init() call has to come from the main thread,
and thus this scenario should be impossible.
It is understood that this is a bad answer if you load a dynamic library
containing the GC after the fact, or don't have control over the code
that creates the threads. That's being worked on. If you need
something that has a better chance of working in such a context, you
might try the gc7 CVS version, which somewhat supports registering
threads after the fact. I think that both gcj and Mono are currently
running into this problem.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Reiterer, Horst
> Sent: Tuesday, January 10, 2006 5:48 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] GC_init from non-main thread fails with segfault
> If the GC is initialized (GC_init) in a thread other than the
> process main thread on a Linux platform (RHEL4, NPTL), the
> implementation causes a segmentation fault because
> GC_push_all_stacks IMHO wrongly assumes that the initiator
> thread equals the process main thread and sets the stack
> bottom accordingly before calling GC_push_all_stack.
> The stack trace is as follows:
> The fault occurs while tracing the stack and accessing
> unmapped memory as a result of the incorrect stack bottom -
> the current thread's stack bottom should IMHO be passed to
> the function, not the main thread's stack bottom.
> The issue can be fixed by reading the stack address via
> pthread_getattr_np and pthread_attr_getstackaddr and falling
> back to GC_stackbottom if the current thread in
> GC_push_all_stacks is the process main thread. Would this be
> a legitimate fix to consider for inclusion? The problem here
> is identifying the main thread, I'm currently doing that by
> comparing the results of getpid() and gettid() but that
> obviously would not work in non-NPTL environments.
> I guess that this case isn't currently being handled because
> the GC is usually initialized right in the main thread. Or am
> I missing something?
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc