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

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

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?

			regards, tom lane