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

Andrew Begel abegel at cs.berkeley.edu
Fri Apr 22 15:52:53 PDT 2005


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:643
>>> #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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: darwin-stack-crawl.patch
Type: application/octet-stream
Size: 2539 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20050422/7002b07d/darwin-stack-crawl.obj


More information about the Gc mailing list