--=.658GZkBSEDCTgM
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On 07 Feb 2003 17:59:39 -0500
"Nathan J. Williams" <nathanw@wasabisystems.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
>       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.
> 

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 <TripleDES@eSlack.org>

Do you BSD?

http://www.hispabsd.org

--=.658GZkBSEDCTgM
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (NetBSD)

iD8DBQE+W/h97+miUKRu9UMRAk56AJ9v+ucuYp4b1nlk7gsBMJG6TNnS3QCcCtji
I5z0qEKSB+oiuRfAt822AuU=
=xuXZ
-----END PGP SIGNATURE-----

--=.658GZkBSEDCTgM--