Skip to content
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

GH-104584: Restore frame->stacktop on optimizer error #108953

Merged
merged 2 commits into from
Sep 6, 2023

Conversation

brandtbucher
Copy link
Member

@brandtbucher brandtbucher commented Sep 5, 2023

@brandtbucher brandtbucher added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump labels Sep 5, 2023
@brandtbucher brandtbucher self-assigned this Sep 5, 2023
@brandtbucher brandtbucher changed the title GH-104584: Restore stack_pointer on optimizer error GH-104584: Restore frame->stacktop on optimizer error Sep 5, 2023
Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

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

Just ran into this by coincidence. Fine to merge, but I do have a quibble (more aimed at @markshannon perhaps :-).

@@ -169,6 +169,7 @@ _PyOptimizer_BackEdge(_PyInterpreterFrame *frame, _Py_CODEUNIT *src, _Py_CODEUNI
if (err <= 0) {
assert(executor == NULL);
if (err < 0) {
_PyFrame_SetStackPointer(frame, stack_pointer);
Copy link
Member

Choose a reason for hiding this comment

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

Oh, interesting. It seems this is needed because when JUMP_BACKWARD calls _PyOptimizer_BackEdge it doesn't update the stack pointer in the frame, it just passes the stack pointer to the optimizer, which upon success passes it to the executor, which will eventually call STORE_SP() to update the stack pointer in the frame. And sure, this PR seems to fix the hole, but I wonder if it wouldn't be more robust to just save it before even calling _PyOptimizer_BackEdge.

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) type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants