[Gc] Solaris and pthread problem

Kenneth C. Schalk ken at xorian.net
Mon Sep 13 15:58:35 PDT 2004

Hans Boehm wrote:
> Before then, I'm inclined to declare malloc redirection with threads
> broken on Solaris X86.  It already is on many other platforms, since
> threads initialization allocates memory, which acquires locks, which
> requires threads to be initialized.  The solution is to only lock if
> a second thread has started, and probably to postpone some GC
> initialization.

I've had a similar chicken-and-egg problem with an overridden new
operator on Tru64.  It seems that some code in the C++ run-time calls
my new operator at a point early enough that calling GC_init causes a
crash.  (It was a while ago that I last looked at this, so I'm a
little fuzzy on the precise details of what went wrong.)

My solution, which I admit leaves a bit to be desired, was to do the

1. Define a static global in the module with the overridden new
operator that indicates whether GC_init has been called.

2. In the overridden new operator, if this variable indicates that
GC_init has been called, call the collector to perform allocations.
Otherwise, use malloc and accumulate all such "early" allocated blocks
into a linked list stored in another static global.

3. Have a static instance of a class which calls GC_init in its
constructor and sets the global to indicate that it has done so.
(This always seems to be called at a point late enough that GC_init
succeeds.)  After GC_init returns, it takes the linked list of "early"
malloced blocks and calls GC_add_roots for each one.

I wouldn't hold this hack up as a good solution (and it obviously can
cause some leaks), but it seems to work.

--Ken Schalk

More information about the Gc mailing list