[Gc] gc6.3 MacOSX problems

Christian Thalinger twisti at complang.tuwien.ac.at
Fri Nov 12 02:17:59 PST 2004


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 


More information about the Gc mailing list