libpthread linkage

[Bryce McKinlay <bryce at albatross dot co dot nz>]

For a long time I've been aware of what I thought was a GC bug that
occured on java test cases which rapidly created a lot of short lived
threads. I've only ever see this occur on an SMP machine, and, to make
debugging more fun, running in gdb or enabling DEBUG_THREADS seemed to
throw the timing off enough that the bug didn't happen there either.

After a lot of investigation I now believe this is a linuxthreads "bug"
involving an interaction between the "old" semaphore code (used by the
GC's thread startup) and condition variable code (used by
Thread.sleep(), Object.notify(), etc). If the timing is exactly right,
pthread_cond_signal and friends can see a value of 1 in the
pthread_descr's "p_nextwaiting" field, which is put there by
__old_sem_wait. This value ends up on the condvar's __c_waiting,
resulting in a segfault when pthread_cond_wait etc are later used.

But it seems to me that the real problem here is that the old semaphore
code is being used at all. This problem shouldn't occur using the new
semaphore code introduced in glibc2.1. When I compile a simple C test
case, it correctly links the "new" sem functions:

$ gcc ex5.c -o ex5 -lpthread
$ nm ./ex5 | grep sem
         U sem_init@@GLIBC_2.1
         U sem_post@@GLIBC_2.1
         U sem_wait@@GLIBC_2.1

However, libgcjgc.so links the old versions:

$ nm /home/bryce/gcc/lib/libgcjgc.so | grep sem
00016b60 B GC_suspend_ack_sem
         U sem_destroy
         U sem_init
         U sem_post
         U sem_wait

Why is this? How can we make sure that the GC's threads code picks up
the correct semaphore functions?

regards

  [ bryce ]