Skip to content

gh-136870: fix data races in instrumentation of bytecode #136994

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 24, 2025

Conversation

kumaraditya303
Copy link
Contributor

@kumaraditya303 kumaraditya303 commented Jul 22, 2025

De-instrumenting code objects modifies the thread local bytecode for all threads as such, holding the critical section on the code object is not sufficient and leads to data races. In this PR, the de-instrumentation is now performed under a stop the world pause as such no thread races with executing the thread local bytecode while it is being de-instrumented.

@colesbury
Copy link
Contributor

I think this makes sense, but it'd be helpful if @DinoV and @mpage can also take a look at it.

From our discussion, locking code objects for de-instrumentation after calling tools isn't sufficient because other threads may be in the middle of running those code objects. We need a stop the world pause there, given the current design.

@mpage
Copy link
Contributor

mpage commented Jul 23, 2025

I think this makes sense, but to make sure I understand correctly, the issue here is that without this change other threads may be using the tools concurrently with their removal. Is that right?

@kumaraditya303
Copy link
Contributor Author

the issue here is that without this change other threads may be using the tools concurrently with their removal. Is that right?

The issue is that while the tools are removed which involves modifying thread local bytecode in MODIFY_BYTECODE for all threads, other threads can be concurrently running the bytecode which causes data race.

@mpage
Copy link
Contributor

mpage commented Jul 23, 2025

The issue is that while the tools are removed which involves modifying thread local bytecode in MODIFY_BYTECODE for all threads, other threads can be concurrently running the bytecode which causes data race.

Ah, ok. We intended to use atomics to avoid data races on the bytecode; looks we missed some places that should use them. Stop-the-world certainly fixes them and is easier to reason about, but it does come with a performance cost. I think that tradeoff is probably acceptable for now and we can revisit later if need be.

@colesbury
Copy link
Contributor

I think we should include a NEWS entry and request a backport to 3.14

@kumaraditya303 kumaraditya303 added topic-free-threading interpreter-core (Objects, Python, Grammar, and Parser dirs) needs backport to 3.14 bugs and security fixes labels Jul 24, 2025
@kumaraditya303 kumaraditya303 enabled auto-merge (squash) July 24, 2025 17:41
@kumaraditya303 kumaraditya303 merged commit 9a6b60a into python:main Jul 24, 2025
47 checks passed
@miss-islington-app
Copy link

Thanks @kumaraditya303 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Jul 24, 2025
…nGH-136994)

De-instrumenting code objects modifies the thread local bytecode for all threads as such, holding the critical section on the code object is not sufficient and leads to data races. Now, the de-instrumentation is now performed under a stop the world pause as such no thread races with executing the thread local bytecode while it is being de-instrumented.
(cherry picked from commit 9a6b60a)

Co-authored-by: Kumar Aditya <kumaraditya@python.org>
@bedevere-app
Copy link

bedevere-app bot commented Jul 24, 2025

GH-137082 is a backport of this pull request to the 3.14 branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-free-threading
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy