gh-118415: Fix issues with local tracing being enabled/disabled on a function #118496
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
colesbury
reviewed
May 2, 2024
colesbury
reviewed
May 3, 2024
Python/instrumentation.c
Outdated
Comment on lines
1003
to
1004
| static inline | ||
| int debug_check_sanity(PyInterpreterState *interp, PyCodeObject *code) |
There was a problem hiding this comment.
Suggested change
| static inline | |
| int debug_check_sanity(PyInterpreterState *interp, PyCodeObject *code) | |
| static int | |
| debug_check_sanity(PyInterpreterState *interp, PyCodeObject *code) |
| @@ -227,6 +218,29 @@ def test_register_callback(self): | |||
| for ref in self.refs: | |||
| self.assertEqual(ref(), None) | |||
|
|
|||
| def test_set_local_trace_opcodes(self): | |||
| return | |||
There was a problem hiding this comment.
The return here doesn't look right
| with l: | ||
| pass | ||
|
|
||
| t = threading.Thread(target=f) |
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]; |
There was a problem hiding this comment.
This doesn't look right. Shouldn't it be initialized to zero?
colesbury
reviewed
May 3, 2024
Python/instrumentation.c
Outdated
| @@ -1000,7 +1000,7 @@ instrumentation_cross_checks(PyInterpreterState *interp, PyCodeObject *code) | |||
| return monitors_equals(code->_co_monitoring->active_monitors, expected); | |||
| } | |||
|
|
|||
| static inline | |||
| static | |||
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.