René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Decoding instructions should handle ENTER_EXECUTOR","articleBody":"There's a variety of places where we walk over an array of instructions, using some variant of\r\n```c\r\nfor (int i = 0; i \u003c num_instructions;) {\r\n    int opcode = instructions[i].op.code;\r\n    // \u003cdecode EXTENDED_ARG\u003e\r\n    opcode = _PyOpcode_Deopt[opcode];  // or _Py_GetBaseOpcode(code, i)\r\n    // \u003chandle opcode\u003e\r\n    i += 1 + _PyOpcode_Caches[opcode];  // or _PyInstruction_GetLength(code, i)\r\n}\r\n```\r\nAll these make the mistake that if `opcode` is `ENTER_EXECUTOR`, it may obscure an underlying `JUMP_BACKWARD` instruction, which has a cache entry.\r\n\r\nI fixed this in gh-107256 for `_PyInstruction_GetLength()` and it was first reported in gh-107082, but there are a number of other occurrences. Basically every time we consult `_PyOpcode_Caches` we should ensure that the index is not `ENTER_EXECUTOR`.\r\n\r\nCC: @markshannon \r\n\r\n---\r\n\r\nPlaces where I found this:\r\n\r\n- [x] _PyInstruction_GetLength\r\n- [x] code_richcompare\r\n- [x] code_hash\r\n- [x] ~_Py_GetBaseOpcode~ **[should not be \"fixed\", it would break callers that need the oparg]**\r\n- [ ] mark_stacks\r\n- [ ] _PyFrame_OpAlreadyRan\r\n- [x] de_instrument?\r\n- [x] initialize_tools?\r\n- [x] remove_tools?\r\n- [x] _PyCode_Quicken?\r\n\r\nThere are possibly others.\r\n\r\n\u003c!-- gh-linked-prs --\u003e\r\n### Linked PRs\r\n* gh-108165\r\n* gh-108188\r\n* gh-108366\r\n* gh-108460\r\n* gh-108482\r\n* gh-108485\r\n* gh-108539\r\n* gh-109420\n* gh-111645\n\u003c!-- /gh-linked-prs --\u003e\r\n","author":{"url":"https://github.com/gvanrossum","@type":"Person","name":"gvanrossum"},"datePublished":"2023-07-25T19:51:22.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":16},"url":"https://github.com/107265/cpython/issues/107265"}