frame.setlineno has serious flaws.

[markshannon]

The frame_setlineno function works in in stages:

• Determine a set of possible bytecode offsets as targets from the line number.
• Compute the stack state for these targets and the current position
• Determine a best target. That is, the first one that has a compatible stack.
• Pop values form the stack and jump.

The 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.

The second step has (at least) three flaws:

• It does not account for NULLs on the stack, making it possible to jump from a stack with NULLs to one that cannot handle NULLs.
• It does not skip over caches, so could produce incorrect stacks by misinterpreting cache entries as normal instructions.
• It is out of date. For example it thinks that PUSH_EXC_INFO pushes three values. It only pushes one.

Setting 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.

Linked PRs

• gh-94438: Add additional cases to mark_stacks with tests #111237
• [3.12] GH-94438: Restore ability to jump over None tests (GH-111237) #111243
• [3.11] GH-94438: Restore ability to jump over None tests (GH-111237) #111338
• GH-94438: Fix RuntimeWarning for jump tests in test_sys_settrace #111341
• [3.12] GH-94438: Fix RuntimeWarning for jump tests in test_sys_settrace (GH-111341) #111369