[gclist] Boehm GC & threads on Linux

[Fergus Henderson]

Hi,

I have a question about the Boehm (et al) conservative collector.
On systems that support thread-local storage, e.g. with pthread_key_create(),
pthread_getspecific(), and pthread_getspecific(), is the collector
supposed to scan thread-local storage?
The documentation doesn't mention thread-local storage.

This question may be related to a bug
that we've been having a bit of trouble tracking down.
The symptom *appears* to be that the collector is collecting
memory that is still live; the program crashes shortly after
the first real collection.
The bug occurs when bootstrapping our compiler for Mercury
in "thread-safe" mode, while using the Boehm (et al) collector,
on some (but not all) versions of Linux.  The problem occurs even when
there is only one thread.  When compiled in "thread-safe" mode,
the Mercury runtime allocates a big structure (that it uses that to
hold some of our virtual machine registers, pointers to the Mercury
stacks, etc.) on the GC'd heap, and puts a pointer to that structure
in thread-local storage.  Memory which ought to be reachable
via that structure seems to be getting collected, and thus
corrupted (e.g. by the collector itself, when it inserts them
on the free list).

At first I thought that this might be due to the collector not
scanning thread-local storage.  But changing it so that the
per-thread structure is allocated using GC_malloc_uncollectable()
rather than GC_malloc() didn't solve the problem, so now I'm not
sure what the problem is.

If you have any hints on how to debug this kind of thing,
they'd be much appreciated.  Thanks.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.