GC failure w/ THREAD_LOCAL_ALLOC ?

Bryce McKinlay bryce@waitaki.otago.ac.nz
Tue Mar 19 19:30:00 GMT 2002


While testing thread local allocation on PowerPC, I ran into a problem 
which is also reproducable on x86. The attached stress-test-case 
GCTest.java will lock up with ~100% reproducability with 
THREAD_LOCAL_ALLOC enabled. It runs fine without THREAD_LOCAL_ALLOC.

What I am seeing in the debugger is most threads waiting in 
GC_suspend_handler, but one thread segfaulting in GC_mark_read. 
libjava's segv handler gets called and the collector is re-entered 
during the stack trace, causing the freeze.

Here's an example:

(gdb) thread 13
[Switching to thread 13 (Thread 11276 (LWP 25862))]#0  0x40632b85 in 
__sigsuspend (
    set=0x41d810d4) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
45      in ../sysdeps/unix/sysv/linux/sigsuspend.c
(gdb) bt
#0  0x40632b85 in __sigsuspend (set=0x41d810d4)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1  0x405f41c9 in __pthread_wait_for_restart_signal (self=0x41d81be0) at 
pthread.c:969
#2  0x405f5f09 in __pthread_alt_lock (lock=0x40533f88, self=0x0) at 
restart.h:34
#3  0x405f2d16 in __pthread_mutex_lock (mutex=0x40533f78) at mutex.c:120
#4  0x403ed4c7 in GC_lock () at ../../../boehm-gc/linux_threads.c:1603
#5  0x403edcfd in GC_malloc_atomic (lb=88) at ../../../boehm-gc/malloc.c:256
#6  0x403ebf47 in GC_local_malloc_atomic (bytes=88)
    at ../../../boehm-gc/linux_threads.c:367
#7  0x40223913 in _Jv_NewPrimArray (eltype=0x8091f50, count=80) at 
include/java-gc.h:53
#8  0x402583c6 in java::lang::Throwable::fillInStackTrace() (this=0x8092ff0)
    at ../../../libjava/gcj/array.h:91
#9  0x40222e32 in _Jv_ThrowSignal (throwable=0x50) at 
../../../libjava/prims.cc:111
#10 0x40222e66 in catch_segv(int) () at ../../../libjava/prims.cc:121
#11 <signal handler called>
#12 0x403efb8e in GC_mark_from (mark_stack_top=0x40599d74, 
mark_stack=0x41d81944,
    mark_stack_limit=0x403e62ac) at ../../../boehm-gc/mark.c:654
#13 0x403ef423 in GC_mark_some (
    cold_gc_frame=0x41d81908 
"¨\020\005\b£ö>@t\235Y@D\031ØA¬b>@x\\>@ì\030¸Aì\030¸At\235Y@ì") at 
../../../boehm-gc/mark.c:357
#14 0x403e660f in GC_stopped_mark (stop_func=0x403e5c78 
<GC_never_stop_func>)
    at ../../../boehm-gc/alloc.c:489
#15 0x403e62ac in GC_try_to_collect_inner (stop_func=0x403e5c78 
<GC_never_stop_func>)
    at ../../../boehm-gc/alloc.c:350
#16 0x403e6be3 in GC_try_to_collect (stop_func=0x403e5c78 
<GC_never_stop_func>)
    at ../../../boehm-gc/alloc.c:735
#17 0x403e6c39 in GC_gcollect () at ../../../boehm-gc/alloc.c:746
#18 0x403e38b9 in _Jv_RunGC() () at ../../../libjava/boehm.cc:401
#19 0x40253d59 in java::lang::Runtime::gc() (this=0x8076fa0)
    at ../../../libjava/java/lang/natRuntime.cc:118
#20 0x40272e9f in java.lang.System.gc() () at 
../../../libjava/java/lang/System.java:129
#21 0x08049651 in GCTest.gc() (this=0x40599d74) at GCTest.java:141
#22 0x080498ec in GCTest.testObjArray() (this=0x8076f30) at GCTest.java:187
#23 0x0804939a in GCTest.run() (this=0x8076f30) at GCTest.java:104
#24 0x40273673 in java.lang.Thread.run() (this=0x40599d74)
    at ../../../libjava/java/lang/Thread.java:132
#25 0x40257edc in _Jv_ThreadRun(java::lang::Thread*) (thread=0x8076f30)
    at ../../../libjava/java/lang/natThread.cc:285
#26 0x403e43a0 in really_start (x=0x8076f30) at 
../../../libjava/posix-threads.cc:375
#27 0x403ed1ea in GC_start_routine (arg=0x807bfe0)
    at ../../../boehm-gc/linux_threads.c:1369
#28 0x405f1c6f in pthread_start_thread (arg=0x41d81be0) at manager.c:284

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: GCTest.java
URL: <http://gcc.gnu.org/pipermail/java/attachments/20020319/dc05d9a5/attachment.ksh>


More information about the Java mailing list