Skip to content

gh-144446: Fix thread-safety of FrameLocalsProxy on executing frames - #156973

Open
kumaraditya303 wants to merge 2 commits into
python:mainfrom
kumaraditya303:gh-144446-frame-locals
Open

gh-144446: Fix thread-safety of FrameLocalsProxy on executing frames#156973
kumaraditya303 wants to merge 2 commits into
python:mainfrom
kumaraditya303:gh-144446-frame-locals

Conversation

@kumaraditya303

@kumaraditya303 kumaraditya303 commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Synchronize FrameLocalsProxy accesses with the frame's owning thread: accessors run under the frame object's critical section and stop the world when the frame is executing on another thread.

This includes #145183 and other fixes like avoid decrefing the old value under stop-the-world etc.

Co-authored-by: Sam Gross colesbury@gmail.com

…rames

Synchronize FrameLocalsProxy accesses with the frame's owning thread:
accessors run under the frame object's critical section and stop the
world when the frame is executing on another thread.

Co-authored-by: Sam Gross <colesbury@gmail.com>
Comment thread Objects/frameobject.c
if (_stw) { \
PyInterpreterState *interp = _PyInterpreterState_GET(); \
_PyEval_StopTheWorld(interp); \
RESULT = CALL; \

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is safe. CALL can end up executing arbitrary Python code via __hash__, which we shouldn't do while the world is stopped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants