gh-118415: Fix issues with local tracing being enabled/disabled on a function#118496
Uh oh!
There was an error while loading. Please reload this page.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
colesbury changed the title Uh oh!
There was an error while loading. Please reload this page.
Python/instrumentation.c Outdated
Comment on lines 1003 to 1004
| static inline | ||
| int debug_check_sanity(PyInterpreterState *interp, PyCodeObject *code) |
Contributor
There was a problem hiding this comment.
Suggested change
| staticinline | |
| intdebug_check_sanity(PyInterpreterState*interp, PyCodeObject*code) | |
| staticint | |
| debug_check_sanity(PyInterpreterState*interp, PyCodeObject*code) |
| self.assertEqual(ref(), None) | ||
| def test_set_local_trace_opcodes(self): | ||
| return |
Contributor
There was a problem hiding this comment.
The return here doesn't look right
| with l: | ||
| pass | ||
| t = threading.Thread(target=f) |
Contributor
There was a problem hiding this comment.
missing import threading or t = Thread(target=f)
Python/instrumentation.c Outdated
| for (int i = 0; i < code_len; i++){ | ||
| code->_co_monitoring->per_instruction_tools[i] = 0; | ||
| int opcode = _PyCode_CODE(code)[i].op.code; | ||
| code->_co_monitoring->per_instruction_tools[i] = _PyOpcode_Deopt[opcode]; |
Contributor
There was a problem hiding this comment.
This doesn't look right. Shouldn't it be initialized to zero?
Python/instrumentation.c Outdated
| } | ||
| static inline | ||
| static |
Contributor
There was a problem hiding this comment.
My previously comment was mostly intended to be that static int should be on one line
colesbury approved these changes May 3, 2024
Contributor
colesbury left a comment
colesbury left a comment There was a problem hiding this comment.
LGTM, but I'd fix the formatting of debug_check_sanity
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When tracing is getting enabled / disabled locally we are currently updating the per-instruction-tools and per-line-tools, either clearing or restoring the non-optimized opcodes that we should fall back to.
When another thread is executing it may see the instrumented opcode and then race with the events and then not see the original opcode as tracing may have changed.
This changes it so that we just always maintain the original opcodes for all of the instructions. It means we can't do some sanity checks but the fact that it's not changing simplifies things.
There's also some assertions that can fire because the local events are being enabled or disabled. At runtime these races are benign, we're just delivering events on other threads in a short window after tracing is disabled or not delivering events in a short window after it's enabled. But the asserts need to lock the code object to be able to get a consistent view on the world.