Repository navigation
Thread spuriously marked dead after interrupting a join call #90882
Description
| BPO | 46726 |
|---|---|
| Nosy | @tim-one, @pitrou, @vstinner, @serhiy-storchaka, @eryksun, @bensimner, @snoopjedi |
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 2022-02-11.23:47:13.610>
labels = ['type-bug', 'library', '3.9', '3.10', '3.11']
title = 'Thread spuriously marked dead after interrupting a join call'
updated_at = <Date 2022-02-14.02:08:58.437>
user = 'https://bugs.python.org/KevinShweh'bugs.python.org fields:
activity = <Date 2022-02-14.02:08:58.437>
actor = 'eryksun'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2022-02-11.23:47:13.610>
creator = 'Kevin Shweh'
dependencies = []
files = []
hgrepos = []
issue_num = 46726
keywords = []
message_count = 17.0
messages = ['413106', '413107', '413108', '413109', '413110', '413118', '413140', '413146', '413155', '413162', '413164', '413166', '413174', '413191', '413202', '413203', '413208']
nosy_count = 8.0
nosy_names = ['tim.peters', 'pitrou', 'vstinner', 'serhiy.storchaka', 'eryksun', 'Kevin Shweh', 'bjs', 'SnoopJeDi']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46726'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']Reacted by Pedro Fonini and Patryk Ludwikowski
Activity
KevinShweh commentedon Feb 11, 2022
This code in Thread._wait_for_tstate_lock:
has a bug. The "if lock.locked()" check doesn't check whether this code managed to acquire the lock. It checks if *anyone at all* is holding the lock. The lock is almost always locked, so this code will perform a spurious call to self._stop() if it gets interrupted while trying to acquire the lock.
Thread.join uses this method to wait for a thread to finish, so a thread will spuriously be marked dead if you interrupt a join call with Ctrl-C while it's trying to acquire the lock. Here's a reproducer:
Interrupt this code with Ctrl-C during the join(), and print(t.is_alive()) will print False.
bensimner commentedon Feb 12, 2022
This is a duplicate of https://bugs.python.org/issue45274
but the patch there did not fix it
I've just added a PR there (or should it go here?) that (i think) fixes this.
The issue is that the lock.locked() call just checks that *someone* has the lock, not that the previous acquire() is what got the lock.
If it's just that the tstate lock is held because the thread is still running, then it's premature to release() the lock.
KevinShweh commentedon Feb 12, 2022
bpo-45274 was a subtly different issue. That was a problem that happened if the thread got interrupted *between* the acquire and the release, causing it to *not* release the lock and *not* perform end-of-thread cleanup.
The fix for that issue caused this issue, which happens if the thread gets interrupted *during* the acquire, in which case it *does* release the lock (that someone else is holding) and *does* perform end-of-thread cleanup even though it's not supposed to do either of those things.
KevinShweh commentedon Feb 12, 2022
The PR you submitted doesn't work, unfortunately. It essentially reintroduces bpo-45274. If this line:
gets interrupted between the acquire and the assignment, locked is still False. That's rare, but so is an interruption between the acquire and the release, which is the original form of bpo-45274.
bensimner commentedon Feb 12, 2022
You are right,
What one really needs here is a way to know *who* owns the lock,
but threading.Lock does not provide that.
The race on := is much smaller than the original race and I suspect in practice will be very hard to hit.
As the original bpo notes, it may not be possible to write a complete fix for this in pure Python, after all there may always be another interrupt between the
exceptand the second attemptedrelease.The issue with the solution was that it turned a relatively hard-to-hit race condition into a really easy-to-hit one, but perhaps the outcome is slightly less worse?
22 remaining items
fix(debug_ext): CTRL+C handling while waiting on gdb process
fix(debug_ext): CTRL+C handling while waiting on gdb process
[wptrunner] Ensure `ManagerGroup.wait()` waits for all threads to stop
[wptrunner] Ensure `ManagerGroup.wait()` waits for all threads to stop
[wptrunner] Ensure `ManagerGroup.wait()` waits for all threads to stop (
Bug 1890086 [wpt PR 45593] - [wptrunner] Ensure `ManagerGroup.wait()`…
abrahammurciano commentedon May 21, 2024
In the 3.13 branch the implementation of
Thread.joinis just a wrapper around_thread._ThreadHandle.join, which is implemented in C.https://github.com/python/cpython/blob/3.13/Lib/threading.py#L1090
Does this mean this issue will be fixed by this change in python3.13?
fofoni commentedon May 22, 2024
Looks like it's really fixed! Just tested the reproducer in the OP:
and:
(Note that this bug was really introduced only in 3.9.)
vstinner commentedon Mar 5, 2025
I close the issue, it has been fixed in Python 3.13.
I confirm, I also see "True" (alive) when I interrupt the reproducer with CTRL+C on Python 3.13 and 3.14.
Python 3.12 has still the issue, but I consider that the bug is a minor issue.
Bug 1890086 [wpt PR 45593] - [wptrunner] Ensure `ManagerGroup.wait()`…
fix(file-agent): let an interrupt reach a wait that has no deadline
fix(file-agent): let an interrupt reach a wait that has no deadline
fix(file-agent): let an interrupt reach a wait that has no deadline