René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"frame.setlineno has serious flaws.","articleBody":"The `frame_setlineno` function works in in stages:\r\n* Determine a set of possible bytecode offsets as targets from the line number. \r\n* Compute the stack state for these targets and the current position\r\n* Determine a best target. That is, the first one that has a compatible stack.\r\n* Pop values form the stack and jump.\r\n\r\nThe first steps is faulty (I think, I haven't demonstrated this) as it might be possible to jump to an instruction involved in frame creation. This should be easy to fix using the new `_co_firsttraceable` field.\r\n\r\nThe second step has (at least) three flaws:\r\n\r\n- [x] It does not account for `NULL`s on the stack, making it possible to jump from a stack with `NULL`s to one that cannot handle `NULL`s.\r\n- [x] It does not skip over caches, so could produce incorrect stacks by misinterpreting cache entries as normal instructions.\r\n- [x] It is out of date. For example it thinks that `PUSH_EXC_INFO` pushes three values. It only pushes one.\r\n\r\nSetting the line number of a frame is only possible in the debugger, so this isn't as terrible as might appear, but it definitely needs fixing.\r\n\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-111237\n* gh-111243\n* gh-111338\n* gh-111341\n* gh-111369\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/markshannon","@type":"Person","name":"markshannon"},"datePublished":"2022-06-30T11:30:04.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":18},"url":"https://github.com/94438/cpython/issues/94438"}