Re: lib/54661: pthread_self() returns invalid value in some circumstances

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR lib/54661; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/54661: pthread_self() returns invalid value in some
 circumstances
Date: Wed, 30 Oct 2019 15:58:41 +0100

 On 30.10.2019 15:55, Joerg Sonnenberger wrote:
 > The following reply was made to PR lib/54661; it has been noted by GNATS=
 .
 >
 > From: Joerg Sonnenberger <joerg%bec.de@localhost>
 > To: Tom Lane <tgl%sss.pgh.pa.us@localhost>
 > Cc: gnats-bugs%netbsd.org@localhost, lib-bug-people%netbsd.org@localhost,
 > 	netbsd-bugs%netbsd.org@localhost
 > Subject: Re: lib/54661: pthread_self() returns invalid value in some
 >  circumstances
 > Date: Wed, 30 Oct 2019 15:52:02 +0100
 >
 >  On Wed, Oct 30, 2019 at 10:44:39AM -0400, Tom Lane wrote:
 >  > Joerg Sonnenberger <joerg%bec.de@localhost> writes:
 >  > > The following reply was made to PR lib/54661; it has been noted by =
 GNATS.
 >  > >  On Wed, Oct 30, 2019 at 06:10:00AM +0000, tgl%sss.pgh.pa.us@localhost wrote:
 >  > >>> pthread_self() sometimes returns an invalid pointer ((void *) -1)=
 ,
 >  > >>> as illustrated in How-To-Repeat.
 >  >
 >  > >  Why do you think it's an invalid pointer? It's an opaque value.
 >  > >  Comparing it against any fixed value is a bug in the caller.
 >  >
 >  > I tend to agree that Python shouldn't be checking for -1, but even
 >  > if it removed that check, this behavior would still be problematic,
 >  > because pthread_self() is returning a value that won't work correctly
 >  > in later thread operations.  For example, it will not compare equal
 >  > to the result of a later pthread_self() if somebody successfully
 >  > loads/initializes libpthread.so in between.
 >  >
 >  > I've now looked at the relevant libpthread code, and what seems to be
 >  > happening is this: libpython.so is invoking libpthread's version of
 >  > pthread_self(), but that is just redirecting to the stub version in
 >  > libc, evidently because pthread__init hasn't been called.  So the
 >  > question is why not.  I see bug fixes in libpthread's CVS history
 >  > that claim to be fixing cases where libpthread is dlopen'd, but
 >  > somehow that's not working here.  Maybe the case where libpthread
 >  > is a dependency of a dlopen'd library isn't covered?
 >  >
 >  > I also kind of wonder why the redirect-to-the-stubs behavior is
 >  > there at all.  Why not just forcibly do pthread__init, if it's not
 >  > been done already, when one of libpthread's functions is called?
 >
 >  We didn't allow dynamic loading of libpthread at all for a long time. I
 >  still believe allowing it was a mistake, but *shrug*. We certainly do
 >  not support calling pthread_create if libpthread was not initially
 >  loaded. As much pthread_self() can only ever return the main thread.
 >
 >  Joerg
 >
 >
 
 I don't know the original use-case, but there is _lwp_self() that is
 guaranteed to work in the same way with and without libpthread.