Invalid check on the result of pthread_self() leads to libpython startup failure

[tgl]

BPO	38646

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-10-30.17:29:23.016>
labels = ['interpreter-core', '3.7', 'type-crash']
title = 'Invalid check on the result of pthread_self() leads to libpython startup failure'
updated_at = <Date 2019-10-30.17:29:23.016>
user = 'https://bugs.python.org/tgl'

bugs.python.org fields:

activity = <Date 2019-10-30.17:29:23.016>
actor = 'tgl'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2019-10-30.17:29:23.016>
creator = 'tgl'
dependencies = []
files = []
hgrepos = []
issue_num = 38646
keywords = []
message_count = 1.0
messages = ['355723']
nosy_count = 1.0
nosy_names = ['tgl']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue38646'
versions = ['Python 3.7']

[tgl]

Assorted code in the Python core supposes that the result of pthread_self() cannot be equal to PYTHREAD_INVALID_THREAD_ID, ie (void *) -1. If it is, you get a crash at interpreter startup. Unfortunately, this supposition is directly contrary to the POSIX specification for pthread_self(), which defines no failure return value; and it is violated by NetBSD's implementation in some circumstances. In particular, we (the Postgres project) are observing that libpython.so fails when dynamically loaded into a host executable that does not itself link libpthread. NetBSD's code always returns -1 if libpthread was not present at main program start, as they do not support forking new threads in that case. They assert (and I can't disagree) that their implementation conforms to POSIX.

A lazy man's solution might be to change PYTHREAD_INVALID_THREAD_ID to some other value like -3, but that's not fixing the core problem that you're violating POSIX by testing for any specific value at all.

Details and background info can be found in this email thread:

https://www.postgresql.org/message-id/flat/25662.1560896200%40sss.pgh.pa.us