Status page

Tue Feb 11 18:15:00 GMT 2003

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