[Gc] GC_init from non-main thread fails with segfault

Reiterer, Horst horst.reiterer at fabasoft.com
Tue Jan 10 05:48:11 PST 2006


Hi,

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:

  /usr/lib/libmono.so.0(GC_push_all_eager+0x50)[0x939bd00]
  /usr/lib/libmono.so.0(GC_push_all_stack+0x4c)[0x939bd7c]
  /usr/lib/libmono.so.0[0x93a3ec4]
  /usr/lib/libmono.so.0(GC_push_all_stacks+0x1f)[0x93a3f5f]
  /usr/lib/libmono.so.0(GC_default_push_other_roots+0x19)[0x939f1a9]
  /usr/lib/libmono.so.0(GC_push_roots+0xd9)[0x939cfb9]
  /usr/lib/libmono.so.0(GC_mark_some+0xd6)[0x939aac6]
  /usr/lib/libmono.so.0(GC_stopped_mark+0xb5)[0x9393c95]
  /usr/lib/libmono.so.0(GC_try_to_collect_inner+0xa4)[0x9393894]
  /usr/lib/libmono.so.0(GC_init_inner+0x336)[0x939d926]
  /usr/lib/libmono.so.0(GC_init+0x2e)[0x939d4ee]

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?

Cheers,

Horst.




More information about the Gc mailing list