Re: PL/Python fails on new NetBSD/PPC 8.0 install

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Wed, Oct 30, 2019 at 9:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> What I'm inclined to do is go file a bug report saying that this
>> behavior contradicts both POSIX and NetBSD's own man page, and
>> see what they say about that.

> From a quick look at the relevant trees, isn't the problem here that
> cpython thinks it can reserve pthread_t value -1 (or rather, that
> number cast to unsigned long, which is the type it uses for its own
> thread IDs):
> https://github.com/python/cpython/blob/master/Include/pythread.h#L21

Possibly. A value of -1 would be quite likely to crash any other
libpthread code it might be passed to, though, since it's evidently
supposed to be a pointer on this implementation. Note that the
point here is that libpython should get a *valid* thread ID that it
can use for other purposes, independently of what the host executable
did, and that we can expect that libpython's calls are not being
routed to the stub implementations.

I've been experimenting with that test program on other platforms,
and I find that FreeBSD 11.0, OpenBSD 6.4, and Fedora 30 all return
plausible-looking pointers with or without -lpthread.

Interestingly, RHEL6 (glibc 2.12) acts more like NetBSD is acting: you get
NULL without -lpthread and a valid pointer with it. Given the lack of
other problem reports about pl/python, I surmise that the glibc
implementation does manage to produce a valid pointer as soon as
libpthread is loaded. Or maybe they fixed glibc far enough back that
nobody has tried recent python with a glibc that worked the old way.

> Further evidence that this is Python's fault is the admission in the
> source code itself that it is "inherently hosed":
> https://github.com/python/cpython/blob/master/Python/thread_pthread.h#L299

I'm not here to defend Python's choices in this area. I'm just
observing that libpthread should produce valid results in a
correctly-linked dynamically loaded library, whether or not the
host executable linked libpthread. NetBSD's code is failing that
test, and nobody else's is.

regards, tom lane