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

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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