Subject: current pthread/sa buglist
To: None <current-users@netbsd.org>
From: Nathan J. Williams <nathanw@wasabisystems.com>
List: current-users
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?
        
        - Nathan


 * 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
      current-users).
    * 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
   -pthread.

 * 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
   failing).
   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.