[Gc] build & gctest failures on darwin/xlc/pthreads

Boehm, Hans hans.boehm at hp.com
Mon May 16 16:09:23 PDT 2005


Thanks.  I applied this to my 6.5 and 7.0 trees.  I renamed the
controlling macro to DARWIN_DONT_PARSE_STACK.  (I think the original
used a naming convention for the stack top/bottom that was inconsistent
with the rest of the GC.  This sidesteps the issue.)

I added documentation to Makefile.direct that discourages use unless
there are known stack unwind problems.

Hans

> -----Original Message-----
> From: Andrew Begel [mailto:abegel at cs.berkeley.edu] 
> Sent: Friday, April 22, 2005 3:53 PM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com; Dan Bonachea
> Subject: Re: [Gc] build & gctest failures on darwin/xlc/pthreads
> 
> 
> Here is a patch to turn off my stack crawler. #define 
> DONTFINDSTACKTOP 
> when you compile darwin_stop_world.c, and it will revert back to the 
> old method of assuming that the pthread_create() function was 
> successfully intercepted before any threads were created in your 
> program. This will work if you init the garbage collector from main() 
> (it assumes you own main()).
> 
> This could easily be turned into a runtime flag if anyone 
> wanted, but I 
> think build-time is appropriate for most uses.
> 
> Andrew
> 
> 
> 
> On Apr 21, 2005, at 5:30 PM, Boehm, Hans wrote:
> 
> > My recollection is that it's also possible to avoid walking 
> the stack 
> > in some interesting cases, but not always?  Would it make sense to 
> > provide a build-time or run-time option to do this either way?
> >
> > Such options aren't always a good thing.  But experience 
> suggests that 
> > it's fairly common to cheat or make mistakes when it comes to 
> > stack-walking ABIs.  In my opinion, it would be nice to have a 
> > fallback.
> >
> > Hans
> >
> >> -----Original Message-----
> >> From: gc-bounces at napali.hpl.hp.com 
> >> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Andrew Begel
> >> Sent: Thursday, April 21, 2005 4:11 PM
> >> To: Dan Bonachea
> >> Cc: gc at napali.hpl.hp.com
> >> Subject: Re: [Gc] build & gctest failures on darwin/xlc/pthreads
> >>
> >>
> >> Hi Dan,
> >>
> >> I contributed the FindTopOfStack() function for Darwin. It should 
> >> work properly with xlc, since it only relies on the MacOSX ABI
> >> being adhered
> >> to. That is controlled by Darwin's runtime system, not the 
> compiler.
> >>
> >> In the FindTopOfStack() code are some commented out print 
> statements,
> >> to print out the frame pointer. Basically, the point of the
> >> code is to
> >> walk the stack frame up until the last stack frame before 
> frame goes
> >> NULL (or something bad, like a non-pointer). So, if you print
> >> out the
> >> frame pointer on every iteration through the loop (and the
> >> savedLR and
> >> savedSP values) and post those back here, we should be able to see
> >> what's wrong with the thread stacks with your compiler.
> >>
> >> Andrew
> >>
> >> On Apr 21, 2005, at 11:50 AM, Dan Bonachea wrote:
> >>
> >>> If I compile with all optimizations disabled, I'm able to
> >> compile, but
> >>> gctest dies with a bus error:
> >>>
> >>> --------------------
> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. 
> >>> 0x000286e8 in FindTopOfStack (stack_start=0) at 
> >>> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/
> >>> darwin_stop_world.c:40
> >>> 40          if (frame->savedSP == NULL) break;
> >>> (gdb) where
> >>> #0  0x000286e8 in FindTopOfStack (stack_start=0) at 
> >>> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/
> >>> darwin_stop_world.c:40
> >>> #1  0x00028504 in GC_push_all_stacks () at 
> >>> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/
> >>> darwin_stop_world.c:76
> >>> #2  0x0001e8b4 in GC_default_push_other_roots () at
> >>>
> >> 
> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/os_dep.c:2053
> >>> #3  0x00020910 in GC_push_roots (all=1,
> >> cold_gc_frame=0xbffff4a4 "")
> >>> at
> >>>
> >> 
> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/mark_rts.c:64
> >> 3
> >>> #4  0x0000fd7c in GC_mark_some (cold_gc_frame=0xbffff4a4 "") at 
> >>> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/mark.c:326
> >>> #5  0x0000c418 in GC_stopped_mark (stop_func=0xbda0
> >>> <GC_never_stop_func>) at 
> >>> 
> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/alloc.c:519
> >>> #6  0x0000bcbc in GC_try_to_collect_inner (stop_func=0xbda0
> >>> <GC_never_stop_func>) at 
> >>> 
> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/alloc.c:366
> >>> #7  0x000070c4 in GC_init_inner () at 
> >>> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/misc.c:782
> >>> #8  0x00008108 in GC_init () at 
> >>> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/misc.c:492
> >>> #9  0x00002a2c in main () at
> >>>
> >> 
> ../../../../src-2.775/runtime/gc-build/pthread/../../gc/tests/test.c:
> >>> 1794
> >>> (gdb)
> >>> --------------------
> >>>
> >>> In both cases the non-pthreaded collector compiles perfectly and 
> >>> gctest works.
> >>>
> >>> Dan
> >
> 



More information about the Gc mailing list