gh-107265: Fix code_richcompare for ENTER_EXECUTOR case#108165
Uh oh!
There was an error while loading. Please reload this page.
Conversation
corona10 changed the title 
gvanrossum left a comment
gvanrossum left a comment There was a problem hiding this comment.
LG, but could you add a test for this? You could add it to test_capi/test_misc.py in TestOptimizerAPI.
Thanks, I added the test, and if I understand the intention correctly. Please let me know if I understand wrongly. |
pydoc test failure is unrelated to this PR, I checked it locally and asked to Discord too |
gvanrossum left a comment
gvanrossum left a comment There was a problem hiding this comment.
Yes, the arg must also be restored, since it is overwritten (with the index of the executor to be used in this code object's array of executors). So it looks like writing the test was useful!
| if (co_instr.op.code==ENTER_EXECUTOR){ | ||
| constintexec_index=co_instr.op.arg; | ||
| _PyExecutorObject*exec=co->co_executors->executors[exec_index]; | ||
| co_instr.op.code=exec->vm_data.opcode; |
There was a problem hiding this comment.
Comparing two code objects must not modify the code object.
The interaction between executor, the specializer and instrumentation is subtle and likely to break without care.
This will leak executors, as it flip-flops between JUMP_BACKWARDS and ENTER_EXECUTOR, or worse if an optimizer assumes that a single instruction will only be seen once.
| if (cp_instr.op.code==ENTER_EXECUTOR){ | ||
| constintexec_index=cp_instr.op.arg; | ||
| _PyExecutorObject*exec=cp->co_executors->executors[exec_index]; | ||
| cp_instr.op.code=exec->vm_data.opcode; |
markshannon commented Aug 21, 2023
Please revert this. It will leak, and may not be safe. |
markshannon commented Aug 21, 2023
gvanrossum commented Aug 21, 2023
@corona10 We can fix this in the hash PR you are working on. |
corona10 commented Aug 21, 2023
Okay got it. |
4 participants
Uh oh!
There was an error while loading. Please reload this page.