-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
gh-107265: Fix initialize/remove_tools for ENTER_EXECUTOR case #108482
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
Conversation
corona10
commented
Aug 25, 2023
•
edited by bedevere-bot
Loading
edited by bedevere-bot
- Issue: Decoding instructions should handle ENTER_EXECUTOR #107265
@gvanrossum |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know this code very well; let's see if @markshannon wants to review it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG except formatting/naming nits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Green light! Thanks so much for powering through these.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the removed opcode != ENTER_EXECUTOR
assertions were correct.
There should never be instrumented ENTER_EXECUTOR
instructions.
I think the correct fix is to remove all ENTER_EXECUTOR
instructions in _Py_Instrument()
prior to calling update_instrumentation_data()
, some thing like:
if (code->co_executors->size > 0) {
// Walk code removing ENTER_EXECUTOR
// Clear all executors
}
@@ -566,7 +566,13 @@ de_instrument(PyCodeObject *code, int i, int event) | |||
_Py_CODEUNIT *instr = &_PyCode_CODE(code)[i]; | |||
uint8_t *opcode_ptr = &instr->op.code; | |||
int opcode = *opcode_ptr; | |||
assert(opcode != ENTER_EXECUTOR); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assertion is correct. Please don't remove assertions, unless you are really sure that they are incorrect.
ENTER_EXECUTOR
should never have associated instrumentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was moved to L574, it will be the same effect no?
@@ -711,7 +717,22 @@ remove_tools(PyCodeObject * code, int offset, int event, int tools) | |||
assert(event != PY_MONITORING_EVENT_LINE); | |||
assert(event != PY_MONITORING_EVENT_INSTRUCTION); | |||
assert(PY_MONITORING_IS_INSTRUMENTED_EVENT(event)); | |||
assert(opcode_has_event(_Py_GetBaseOpcode(code, offset))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also correct, provided the assertion assert(PY_MONITORING_IS_INSTRUMENTED_EVENT(event))
is true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it will guarantee that the opcode is not ENTER_EXECUTOR?
opcode = code->_co_monitoring->lines[i].original_opcode; | ||
} | ||
assert(opcode != ENTER_EXECUTOR); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assert should be moved before the original if (opcode == INSTRUMENTED_LINE) {
, we shouldn't get here with and ENTER_EXECUTOR
present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move it to L1310 will be enough?
Note that it is OK to have instrumented instructions and |
I will try to apply this approach :) |
…OR case (pythongh-108482)" This reverts commit 6cb48f0.