[Gc] gc6.3 MacOSX problems

Andrew Begel abegel at cs.berkeley.edu
Sat Nov 13 09:58:21 PST 2004

On Nov 13, 2004, at 5:48 AM, Stefan Ring wrote:

> Andrew Begel wrote:
>> I wrote the code that's crashing for you. It should work fine as long 
>> as your stack frames conform to the Darwin/OSX PowerPC ABI. I'm not 
>> sure how your cacao implements Java stack frames, but if it uses the 
>> pthread stack to do it, the stack frame walker's purpose is to find 
>> the top of the stack given a pointer on the stack. Since the stack 
>> frame is defined in the ABI, I took advantage of knowing where the 
>> link register was put to walk the stack back to the top. If your 
>> stack doesn't conform, then this code will definitely crash.
> That's very good info, thanks. We do some nasty stuff on the stack so, 
> after reading this, it's not surprising that it crashes. What exactly 
> is the advantage of your stack walking approach compared to the 
> earlier way of doing things, and what could we expect by somehow 
> disabling it (backing out your changes somehow)?

The only reliable (read: robust) way to find the top of the stack with 
a pthread system is to intercept pthread_create() and create the stack 
at a known location. That's how the Unix variants of libgc work. But 
this only works when the libgc is loaded before any other library in 
your application, to make sure it intercepts your app before *any* 
threads have been created. When using libgc with a JNI library that is 
loaded by Apple's Java, you can't control their thread creation, since 
your JNI library does not run main(), nor is loaded before Java. On ELF 
systems, you can setenv LD_PRELOAD in your environment to force libgc 
to load early, before Java, but that doesn't work on the Mac. My change 
to the libgc code recognizes that since most (including Java) apps on 
the Mac that would use a gc like Boehm-Weiser obey the MacOSX ABI, we 
could discover the top of the stack after the fact, by walking all the 
existing Mach threads' (one-to-one correspondence with pthreads) 
stacks. It's easy to iterate over the Mach threads (one disadvantage is 
that you only get binary compatibility within an OSX major version), 
but only if the stacks obey the ABI. In all of the programs I had 
tested (gcc compiled C and C++ and Java apps) the ABI was never 


More information about the Gc mailing list