Exceptions when using threading with 3.13, but only in a 32-bit ARM chroot.

[Zabolekar]

Bug report

Bug description:

Python in question is the regular 3.13, not the free-threading build. This is the smallest example that still causes the exception:

# bug.py

import threading

def f():
    pass

t = threading.Thread(target=f)
t.start()
t.join()

When executing it with python -i bug.py, then exiting with Ctrl+D, the following happens:

Exception ignored in: <function _DeleteDummyThreadOnDel.__del__ at 0xf67448e8>
Traceback (most recent call last):
  File "/usr/pkg/lib/python3.13/threading.py", line 1383, in __del__
TypeError: 'NoneType' object does not support the context manager protocol

The only environment where i can reproduce it is a 32-bit chroot with Python 3.13.2 on a 64-bit NetBSD 10.1 ARM install. In particular, it doesn't happen with Python 3.12 in the same chroot, it doesn't happen with Python 3.13 in an otherwise identical 64-bit chroot on the same system, and it doesn't happen in a 32-bit chroot with Python 3.13 on 64-bit x86 Debian. I didn't test NetBSD on x86 or Linux on ARM, though.

I realize that developers might not have access to 64-bit ARM hardware running NetBSD, and will gladly follow debugging instructions if needed.

It doesn't happen with a simple python bug.py, and, for some reason, it doesn't even happen with from threading import Thread instead of import threading and using threading.Thread. It might be unreliable in other ways. This is why I have to give another example, which fails reliably every time.

When creating a venv, activating it and calling pip list, I get the following output:

Package Version
------- -------
pip     24.3.1
Exception ignored in: <function _DeleteDummyThreadOnDel.__del__ at 0xf67448e8>
Traceback (most recent call last):
  File "/usr/pkg/lib/python3.13/threading.py", line 1383, in __del__
TypeError: 'NoneType' object does not support the context manager protocol

Trying to debug hasn't been helpful. There is a variable _active_limbo_lock which is None but expected to be a context manager, and I have no idea why. I can speculate that it might be related to #130522, where the error message is the same and is caused by _active_limbo_lock being None as well.

I would gladly test it with a newer pip, but I can't, because pip install -U pip raises a different exception, also in threading.py, and then crashes:

Requirement already satisfied: pip in /313/lib/python3.13/site-packages (24.3.1)
Collecting pip
  Downloading pip-25.1.1-py3-none-any.whl.metadata (3.6 kB)
Downloading pip-25.1.1-py3-none-any.whl (1.8 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0.0/1.8 MB ? eta -:--:--Fatal Python error: _PySemaphore_PlatformWait: unexpected error from semaphore: 14
Python runtime state: initialized

Current thread 0xf7188c00 (most recent call first):
  File "/usr/pkg/lib/python3.13/threading.py", line 363 in wait
  File "/usr/pkg/lib/python3.13/threading.py", line 659 in wait
  File "/313/lib/python3.13/site-packages/pip/_vendor/rich/live.py", line 29 in run
  File "/usr/pkg/lib/python3.13/threading.py", line 1041 in _bootstrap_inner
  File "/usr/pkg/lib/python3.13/threading.py", line 1012 in _bootstrap

Thread 0xf8f7ec00 (most recent call first):
  File "/usr/pkg/lib/python3.13/ssl.py", line 1138 in read
  File "/usr/pkg/lib/python3.13/ssl.py", line 1304 in recv_into
  File "/usr/pkg/lib/python3.13/socket.py", line 719 in readinto
  File "/usr/pkg/lib/python3.13/http/client.py", line 479 in read
  File "/313/lib/python3.13/site-packages/pip/_vendor/cachecontrol/filewrapper.py", line 98 in read
  File "/313/lib/python3.13/site-packages/pip/_vendor/urllib3/response.py", line 527 in _fp_read
  File "/313/lib/python3.13/site-packages/pip/_vendor/urllib3/response.py", line 561 in read
  File "/313/lib/python3.13/site-packages/pip/_vendor/urllib3/response.py", line 622 in stream
  File "/313/lib/python3.13/site-packages/pip/_internal/network/utils.py", line 65 in response_chunks
  File "/313/lib/python3.13/site-packages/pip/_internal/cli/progress_bars.py", line 55 in _rich_progress_bar
  File "/313/lib/python3.13/site-packages/pip/_internal/network/download.py", line 184 in __call__
  File "/313/lib/python3.13/site-packages/pip/_internal/operations/prepare.py", line 469 in _complete_partial_requirements
  File "/313/lib/python3.13/site-packages/pip/_internal/operations/prepare.py", line 554 in prepare_linked_requirements_more
  File "/313/lib/python3.13/site-packages/pip/_internal/resolution/resolvelib/resolver.py", line 179 in resolve
  File "/313/lib/python3.13/site-packages/pip/_internal/commands/install.py", line 379 in run
  File "/313/lib/python3.13/site-packages/pip/_internal/cli/req_command.py", line 67 in wrapper
  File "/313/lib/python3.13/site-packages/pip/_internal/cli/base_command.py", line 96 in _inner_run
  File "/313/lib/python3.13/site-packages/pip/_internal/cli/base_command.py", line 105 in _run_wrapper
  File "/313/lib/python3.13/site-packages/pip/_internal/cli/base_command.py", line 231 in _main
  File "/313/lib/python3.13/site-packages/pip/_internal/cli/base_command.py", line 157 in main
  File "/313/lib/python3.13/site-packages/pip/_internal/cli/main.py", line 80 in main
  File "/313/bin/pip", line 8 in <module>
[1]   Abort trap (core dumped) pip install -U pip

CPython versions tested on:

3.13

Operating systems tested on:

Other

[picnixz]

Could be some finalization task where the dummy context is overwritten for some reason, or there is some race. Do you want to take a look @ZeroIntensity?

[ZeroIntensity]

Thanks for the report. This is a duplicate of #130522, but interestingly, this is the smallest repro we've seen yet. This bug happens under very rare circumstances and I can't for the life of me figure out why. I think it has to do with some sort of race condition during module finalization, but I'll continue investigating.