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
Reactions are currently unavailable
The frame_setlineno function works in in stages:
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:
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