]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[3.13] gh-130115: fix thread identifiers for 32-bit musl (GH-130391) (GH-132089)
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Fri, 4 Apr 2025 20:57:35 +0000 (22:57 +0200)
committerGitHub <noreply@github.com>
Fri, 4 Apr 2025 20:57:35 +0000 (22:57 +0200)
commit240c200ccef9ad31dea3977d70d3ab4177a1212d
tree32ec64b8ed6ddc7b815ef225dccbbd89e4ff0389
parent53752d20c4f9258ac4b96332d60e40a8666f78f1
[3.13] gh-130115: fix thread identifiers for 32-bit musl (GH-130391) (GH-132089)

CPython's pthread-based thread identifier relies on pthread_t being able
to be represented as an unsigned integer type.

This is true in most Linux libc implementations where it's defined as an
unsigned long, however musl typedefs it as a struct *.

If the pointer has the high bit set and is cast to PyThread_ident_t, the
resultant value can be sign-extended [0]. This can cause issues when
comparing against threading._MainThread's identifier. The main thread's
identifier value is retrieved via _get_main_thread_ident which is backed
by an unsigned long which truncates sign extended bits.

  >>> hex(threading.main_thread().ident)
  '0xb6f33f3c'
  >>> hex(threading.current_thread().ident)
  '0xffffffffb6f33f3c'

Work around this by conditionally compiling in some code for non-glibc
based Linux platforms that are at risk of sign-extension to return a
PyLong based on the main thread's unsigned long thread identifier if the
current thread is the main thread.

[0]: https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Arrays-and-pointers-implementation.html

---------
(cherry picked from commit 72123063ddee84bb2c9d591a23f420997e35af5a)

Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Co-authored-by: Vincent Fazio <vfazio@gmail.com>
Misc/NEWS.d/next/Core_and_Builtins/2025-02-21-00-12-24.gh-issue-130115.mF-rP6.rst [new file with mode: 0644]
Python/thread_pthread.h