Subject: current pthread/sa buglist
To: None <email@example.com>
From: Nathan J. Williams <firstname.lastname@example.org>
Date: 02/07/2003 17:59:39
Here's my list of known issues with pthread and/or SA stuff, as of the
latest fixes I've done today.
Did I miss anything?
* SA + MP -> boom (variety of reports).
* preempt() in a SA process can lose state in the kernel (Nick
Hudson: glib2 maintest, src/regress/lib/libpthread/preempt1).
* mozilla "acts funny":
* hangs sometimes when printing (Tom Ivar Helbekkmo on current-users)
* hangs sometimes when switching tabs (Steve Bellovin on
* hangs sometimes when writing mail (Marti Kuparinen and Daniel
Carosone on wcurrent-users).
* on alpha, dies without core dumping or displaying anything
(Jarkko Teppo on current-users).
* mozilla won't build on powerpc platforms due to gcc's weird option
handling (accepting -pthread when it's not valid) and mozilla's
semi-bogus "just see if -pthread errors out" configure test for
* glib's configure test for a OSF/1 dlopen("libpthread.so") problem
fails and it concludes that RTLD_GLOBAL doesn't work. This breaks
the gmodule interface (and is the root cause of PR 20050, galeon
Details: glib has a configure test that dlopen's libpthread.so,
which causes __isthreaded to be set to 1, which causes the mutex
stubs in libc to abort. The abort exit is nonzero and causes the
configure test to believe that RTLD_GLOBAL is broken. The pthread
library is unlikely to support being dlopen'd (conflicts between
libpthread's routines and libc's weak stubs), and this configure
test probably exists in several packages. Should
dlopen("libpthread") be allowed to fail more quietly?
* sem_wait() in a single-threaded process fails with an
assertion. Needs handling similar to pthread_cond_timedwait().
* stack of main thread is smaller than ulimit suggests (breaks some
Python stuff; reported by Matthias Drochner).
* vfork() + exec*() leaves libc environment lock locked in parent
process (root cause of PR 20214, analyzed by Matthias Drochner).
* vfork() should stop all LWPs in the parent (problem found by
inspection by Matthias Drochner, while working on the above problem).
* ld.elf_so is not thread-safe.
* stub resolver in libc is not thread-safe.