[Gc] gc6.3 MacOSX problems

Andrew Begel abegel at cs.berkeley.edu
Fri Nov 12 13:52:05 PST 2004


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.

Andrew


On Nov 12, 2004, at 2:17 AM, Christian Thalinger wrote:

> Hi!
>
> We have included the boehm gc in our jvm called cacao. Since we have
> upgraded to version 6.3, we have some serious problems on our powerpc
> port (it works perfectly on i386, x86_64, alpha and mips). We get an
> segfault in one of the first collections. When i link the same object
> files against the libgc.a of gc6.2, it works without a glitch.
>
> Attached is the gdb output plus backtrace from GCBench and
> JavaPerformance (can't find a link in google anymore).
>
> GCBench.c and MT_GCBench.c are working perfectly with gc6.3 on the same
> box.
>
>
> cdbook:~/cacao/cacaodev/tst twisti$ uname -a
> Darwin cdbook.complang.tuwien.ac.at 7.2.0 Darwin Kernel Version 7.2.0:
> Thu Dec 11 16:20:23 PST 2003; root:xnu/xnu-517.3.7.obj~1/RELEASE_PPC
> Power Macintosh powerpc
> cdbook:~/cacao/cacaodev/tst twisti$ gdb ../cacao
> GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT
> 2004)
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and 
> you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "powerpc-apple-darwin".
> Reading symbols for shared libraries ... done
> (gdb) r GCBench
> Starting program: /Users/twisti/cacao/cacaodev/cacao GCBench
> Reading symbols for shared libraries . done
> Garbage Collector Test
>  Stretching memory with a binary tree of depth 18
>  Total memory available=892928 bytes  Free memory=212992 bytes
>  Creating a long-lived binary tree of depth 16
>  Creating a long-lived array of 500000 doubles
>  Total memory available=10739712 bytes  Free memory=1863680 bytes
> Creating 33824 trees of depth 4
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> FindTopOfStack (stack_start=4294443008) at darwin_stop_world.c:48
> 48          if ((frame->savedLR & ~3) == 0) break; /* if the next LR is
> bogus, stop */
> (gdb) bt
> #0  FindTopOfStack (stack_start=4294443008) at darwin_stop_world.c:48
> #1  0x00099174 in GC_push_all_stacks () at darwin_stop_world.c:76
> #2  0x0009b834 in GC_mark_some (cold_gc_frame=0xbffff3c4 "") at
> mark.c:326
> #3  0x00093ae0 in GC_stopped_mark (stop_func=0x93070
> <GC_never_stop_func>) at alloc.c:520
> #4  0x000936b4 in GC_try_to_collect_inner (stop_func=0x6a) at
> alloc.c:367
> #5  0x000946d0 in GC_collect_or_expand (needed_blocks=106,
> ignore_off_page=0) at alloc.c:1027
> #6  0x00094890 in GC_allocobj (sz=602224, kind=952200) at alloc.c:1078
> #7  0x00096074 in GC_generic_malloc_inner (lb=602224, k=951968) at
> malloc.c:136
> #8  0x000961c4 in GC_generic_malloc (lb=24, k=1) at malloc.c:192
> #9  0x00096444 in GC_malloc (lb=1) at malloc.c:311
> #10 0x00091920 in stackcall_malloc (p=Cannot access memory at address
> 0x69
> ) at boehm.c:69
> #11 0x00091b34 in heap_allocate (bytelength=24, references=1,
> finalizer=0x0) at boehm.c:140
> #12 0x00002ad0 in builtin_new (c=0x4d1210) at builtin.c:474
> #13 0x00382dc4 in ?? ()
> #14 0x00382e08 in ?? ()
> #15 0x0082423c in ?? ()
> Cannot access memory at address 0xfff80000
> Cannot access memory at address 0xfff80000
> (gdb) r JavaPerformance
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /Users/twisti/cacao/cacaodev/cacao JavaPerformance
> Arithmetic time
>
> ggT (24,42)...(LOG: Java_java_lang_VMSecurityManager_currentClassLoader
> LOG: init_systemclassloader
> LOG: Initializing new system class loader
> LOG: leaving system class loader
> LOG: Java_java_lang_VMRuntime_nativeLoad
> LOG: ./libjavalang.so
> 9.8E-5ms 49ms/500000)
> 13!...(0.001924ms 962ms/500000)
>
> Calling time
>
> Static function call...(3.4E-5ms 17ms/500000)
> Static final function call...(3.6E-5ms 18ms/500000)
> Static synchronized function call...(0.001352ms 676ms/500000)
> Static function call in try catch block...(3.6E-5ms 18ms/500000)
> Static exception throwing function call...(0.0146ms 73ms/5000)
> Method call...(5.2E-5ms 26ms/500000)
> Final method call...(5.0E-5ms 25ms/500000)
> Synchronized method call...(0.001358ms 679ms/500000)
> Method call in try catch block...(5.2E-5ms 26ms/500000)
> Exception throwing method call...
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> GC_mark_from (mark_stack_top=0x2b59e8, mark_stack=0x2b40a8,
> mark_stack_limit=0x2bc0a8) at mark.c:759
> 759               deferred = *limit;
> (gdb) bt
> #0  GC_mark_from (mark_stack_top=0x2b59e8, mark_stack=0x2b40a8,
> mark_stack_limit=0x2bc0a8) at mark.c:759
> #1  0x0009b804 in GC_mark_some (cold_gc_frame=0xbffffebc "=twisti") at
> mark.c:321
> #2  0x0009b804 in GC_mark_some (cold_gc_frame=0xbffff0c4 "") at
> mark.c:321
> #3  0x00093ae0 in GC_stopped_mark (stop_func=0x93070
> <GC_never_stop_func>) at alloc.c:520
> #4  0x000936b4 in GC_try_to_collect_inner (stop_func=0x6d) at
> alloc.c:367
> #5  0x000946d0 in GC_collect_or_expand (needed_blocks=109,
> ignore_off_page=0) at alloc.c:1027
> #6  0x00094890 in GC_allocobj (sz=602224, kind=952200) at alloc.c:1078
> #7  0x00096074 in GC_generic_malloc_inner (lb=602224, k=20) at
> malloc.c:136
> #8  0x000961c4 in GC_generic_malloc (lb=16, k=1) at malloc.c:192
> #9  0x00096444 in GC_malloc (lb=1) at malloc.c:311
> #10 0x00091920 in stackcall_malloc (p=Cannot access memory at address
> 0x69
> ) at boehm.c:69
> #11 0x00091b34 in heap_allocate (bytelength=16, references=1,
> finalizer=0x0) at boehm.c:140
> #12 0x00002ad0 in builtin_new (c=0x2c94d0) at builtin.c:474
> #13 0x0001c800 in native_new_and_init (c=0x2c94d0) at native.c:558
> #14 0x0008e72c in Java_java_lang_VMThrowable_fillInStackTrace
> (env=0xd846c, clazz=0x2c94d0, par1=0x684480) at VMThrowable.c:63
> #15 0x0084e074 in ?? ()
> #16 0x00381228 in ?? ()
> #17 0x003851fc in ?? ()
> (gdb)
>
>
> There is one oddity, it seems that GCBench is getting further in gdb
> than without:
>
> cdbook:~/cacao/cacaodev/tst twisti$ ../cacao GCBench
> Garbage Collector Test
>  Stretching memory with a binary tree of depth 18
>  Total memory available=892928 bytes  Free memory=212992 bytes
>  Creating a long-lived binary tree of depth 16
> Segmentation fault
>
>
> I've also tried it on a Darwin 6.8 with the same results.
>
> Any idea?
>
> TWISTI
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list