gh-143123: Protect against recursive tracer calls/finalization #143126
Conversation
Fidget-Spinner
changed the title
|
Can we have a test for this? |
The reproducer provided by the OP requires installation of a package to crash. I don't think we can unit test this if that's the case. |
markshannon
left a comment
markshannon
left a comment
There was a problem hiding this comment.
What is the root issue here, and does this fix it?
Is the problem that we are unable to distinguish between tracing happening in an invocation of _PyEval_EvalFrameDefault higher up the call stack and tracing happening in this invocation of _PyEval_EvalFrameDefault?
So we start/stop tracing when we shouldn't?
| return 0; | ||
| } | ||
| if (_tstate->jit_tracer_state.initial_state.func == NULL) { | ||
| // gh-143123: It is possible for another function to finalize the current |
There was a problem hiding this comment.
What do you mean by "another function"? Which other function?
| // return immediately without optimization. | ||
| return 0; | ||
| } | ||
| if (_tstate->jit_tracer_state.initial_state.func == NULL) { |
There was a problem hiding this comment.
We shouldn't be able to get into this state, should we?
This seems like it should be an assert and the fix should be elsewhere.
Yes I suspect that's the case. |
|
@Fidget-Spinner
|
2 participants
_PyOptimizer_Optimize#143123