Subject: Re: current pthread/sa buglist
To: Nathan J. Williams <>
From: Sergio Jimenez Romero <>
List: current-users
Date: 02/26/2003 00:12:56
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On 07 Feb 2003 17:59:39 -0500
"Nathan J. Williams" <> 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
>       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("") 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,
>    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.

Best Regards.

TripleDES <>

Do you BSD?

Content-Type: application/pgp-signature

Version: GnuPG v1.2.1 (NetBSD)