Status page

Boehm, Hans hans_boehm@hp.com
Tue Feb 11 19:30:00 GMT 2003


It looks like gcj is built with thread support, but the gc is built without.

I forgot about this particular failure mode.  Basically it's crashing because the allocator finds itself running on a different stack from the one it's expecting.  It's not surprising that that would happen in this configuration.

This build looks extremely unhealthy, in spite of the mixed test results.  The tests pass only because they're mostly single-threaded and don't garbage-collect.

Hans

> -----Original Message-----
> From: Andreas Tobler [mailto:toa@pop.agri.ch]
> Sent: Tuesday, February 11, 2003 10:15 AM
> To: Boehm, Hans
> Cc: 'Andrew Haley'; Jeff Sturm; java@gcc.gnu.org
> Subject: Re: Status page
> 
> 
> Boehm, Hans wrote:
> > How is it being built?
> 
> Right now on darwin everything is built statically.
> Threads in the main gcc are from type posix.
> This is the config I use:
> 
> --enable-languages=c,c++,java --enable-libgcj --disable-multilib 
> --enable-threads
> 
> The libgcj.spec:
> *lib: -lgcj -lm   -lpthread    -ldl %(libgcc) %(liborig)
> 
> *jc1:  -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc 
> -fkeep-inline-functions
> 
> 
> > 
> > I suspect very few of the tests require a working GC.  This 
> is probably OK, so long as we don't conclude that a port 
> works just because there are few test failures.
> > 
> > Currently the collector just doesn't know about threads on 
> Darwin.  This means I would expect a multithreaded build to:
> > 
> > 1) Die if it ever tries to collect in a thread other than 
> the main one.
> > 
> > 2) Not ever scan local variables in threads other than the 
> main one.  Thus objects referenced by those will be 
> prematurely collected.
> > 
> > 3) Not stop other threads while it's collecting.  This can 
> also cause objects to be prematurely collected.  But 
> empirically, the probability of that is fairly low; you may 
> only see it once every few dozen collections.
> > 
> 
> What I see as a failure from boehm-gc is this:
> [titanium:objdir/powerpc-apple-darwin6.0/libjava] andreast% ./gij 
> Thread_Interrupt
> wait()
> interrupted - ok
> sleep()
> interrupted - ok
> Error: join() from main thread timed out
> join()
> interrupted - ok
> Bus error
> 
> A gdb backtrace shows this (this is why I think it is in boehm):
> 
> Starting program: 
> /Volumes/xufs/gcc-cvs/objdir/powerpc-apple-darwin6.0/libjava/gij 
> Thread_Interrupt
> [Switching to process 26784 thread 0xb03]
> Reading symbols for shared libraries ... done
> wait()
> [Switching to process 26784 thread 0x1203]
> 
> Program received signal SIGUSR2, User defined signal 2.
> [Switching to process 26784 thread 0x1203]
> 0x9003eaa8 in semaphore_wait_signal_trap ()
> (gdb) c
> Continuing.
> interrupted - ok
> Error: join() from main thread timed out
> [Switching to process 26784 thread 0x1403]
> 
> Program received signal SIGUSR2, User defined signal 2.
> [Switching to process 26784 thread 0x1403]
> 0x90020d20 in _pthread_body ()
> (gdb) c
> Continuing.
> sleep()
> interrupted - ok
> [Switching to process 26784 thread 0x1503]
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> [Switching to process 26784 thread 0x1503]
> 0x000252a8 in GC_clear_stack_inner (arg=0x898e60 "", 
> limit=3221225072) 
> at /Volumes/xufs/gcc-cvs/gcc/boehm-gc/misc.c:263
> 263     {
> (gdb) bt
> #0  0x000252a8 in GC_clear_stack_inner (arg=0x898e60 "", 
> limit=3221225072) at /Volumes/xufs/gcc-cvs/gcc/boehm-gc/misc.c:263
> #1  0x000252e4 in GC_clear_stack_inner (arg=0x898e60 "", 
> limit=3221225072) at /Volumes/xufs/gcc-cvs/gcc/boehm-gc/misc.c:268
> [snip]
> #552 0x000254b4 in GC_clear_stack (arg=0x898e60 "") at 
> /Volumes/xufs/gcc-cvs/gcc/boehm-gc/misc.c:339
> #553 0x00026c64 in GC_malloc_atomic (lb=356) at 
> /Volumes/xufs/gcc-cvs/gcc/boehm-gc/malloc.c:259
> #554 0x0000825c in _Jv_AllocBytes(int) (size=356) at 
> /Volumes/xufs/gcc-cvs/gcc/libjava/boehm.cc:339
> #555 0x00045620 in _Jv_InterpMethod::compile(void const* const*) 
> (this=0x897f18, insn_targets=0x1c8278) at 
> /Volumes/xufs/gcc-cvs/gcc/libjava/interpret.cc:330
> #556 0x00048cf0 in _Jv_InterpMethod::run(void*, ffi_raw*) 
> (this=0x897f18, retp=0xf0101e00, args=0xf0101ca0) at 
> /Volumes/xufs/gcc-cvs/gcc/libjava/interpret.cc:1037
> #557 0x0006fd9c in ffi_java_translate_args (cif=0x892bdc, 
> rvalue=0xf0101e00, avalue=0xf0101ca0, user_data=0x44b1c) at 
> /Volumes/xufs/gcc-cvs/gcc/libffi/src/java_raw_api.c:308
> #558 0x000736c4 in ffi_closure_helper_DARWIN (closure=0x6fd30, 
> rvalue=0xf0101e00, pgr=0x10, pfr=0x898e60, pst=0x10) at 
> /Volumes/xufs/gcc-cvs/gcc/libffi/src/powerpc/ffi_darwin.c:707
> #559 0x000ad19c in ffi_closure_ASM ()
> #560 0x00015460 in _Jv_ThreadRun(java::lang::Thread*) 
> (thread=0x83f280) 
> at /Volumes/xufs/gcc-cvs/gcc/libjava/java/lang/natThread.cc:285
> #561 0x00016054 in really_start(void*) (x=0x872f48) at 
> /Volumes/xufs/gcc-cvs/gcc/libjava/posix-threads.cc:375
> #562 0x90020d48 in _pthread_body ()
> Current language:  auto; currently c
> 
> > Do current versions of Darwin support pthread_kill()?  If 
> so, this may no longer be that hard to fix.
> 
> According to the header pthread.h yes.
> The man page says:
> pthread_kill() conforms to ISO/IEC 9945-1:1996 (``POSIX.1'')
> 
> 
> Andreas
> 
> 
> 
> 



More information about the Java mailing list