Subject: Re: current pthread/sa buglist
To: Nathan J. Williams <email@example.com>
From: Sergio Jimenez Romero <firstname.lastname@example.org>
Date: 02/26/2003 00:12:56
Content-Type: text/plain; charset=US-ASCII
On 07 Feb 2003 17:59:39 -0500
"Nathan J. Williams" <email@example.com> wrote:
> 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
> * 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.
I have some similar problems (like mozilla) with phoenix, but it's a bit strange because it's phoenix-linux. It doesn't make any core file and doesn't print any error.
If it hasn't any point with pthreads, I'm sorry.
Do you BSD?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (NetBSD)
-----END PGP SIGNATURE-----