Add a “step back” Feature to pdb

[the-osiris]

Proposal:

Summary

I’d like to propose adding support for a “step back” (reverse stepping) feature in the pdb debugger. Today, pdb supports forward stepping (step, next, until), but there is no mechanism to move execution backward to a previous line or state. This feature would make pdb more powerful for debugging complex execution paths, especially when investigating state changes, loops, and regressions.

Motivation

Reverse debugging is supported in several modern debuggers (e.g., gdb with process recording, rr, C# debugger “Step Back”, and many JavaScript tooling environments). It is particularly useful when you:
• Step too far and want to return to the previous state
• Inspect how a particular variable changed across steps
• Debug loops and recursive calls
• Investigate nondeterministic behavior or regressions more efficiently

Today, pdb users must restart their program or manually set breakpoints to re-enter earlier states, which is slow and unintuitive compared to modern debugging workflows.

Possible Approaches (Open for Discussion)

There are several potential designs, and I am looking for guidance from core maintainers:

1. Record & replay mode (lightweight time-travel)
   • Record snapshots of frames, locals/globals, and last executed lines.
   • Rewind to the last recorded state when the user runs back or reverse-step.

2. AST- or bytecode-based re-execution
   • Restart execution from an earlier safe point up to the target line.
   • Similar to how some trace-based debuggers “rewind” by re-running code deterministically.

3. Integration with existing tracing hooks
   • pdb already uses sys.settrace; a buffer of recent trace events could allow stepping backward.

4. Minimal prototype
   • Support only a “single step back” (undo the last step) as a starting point.
   • Later could expand to multiple steps / reverse-continue.

I’m happy to develop an initial prototype once there is agreement on a feasible direction.

Key Questions for Maintainers

• Is a step back feature appropriate for pdb’s scope?
• Should this begin as an experimental or opt-in feature?
• Would a single-step-back MVP be acceptable for a first contribution?

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[gaogaotiantian]

Unfortunately, that's not possible at Python scope. I believe it was discussed a few times before (I can't find the issue), and you can make a prototype that works on simple programs. I even did a working prototype. However, it's just theortically impossible to work on all occasions.

The core issue is - you can't get a reliable "snapshot" of CPython current status, unless you make a memory dump at C level. The easiet one to understand is mutables. For example, how do you snapshot a list? Do you shallow copy it? Deep copy it? Because the content could be changed if you just save it to another variable. It's almost impossible to keep the correct relations among all the mutable objects.

If you attempt to solve that issue, what about the C-Extension status? Any execution could change internal C-Extension status, which is not even exposed to Python. It's literally impossible to store that at Python level.

The memory usage and performance hit would be crazy but I'll let that pass for now.

The only way that seems slightly feasible to me is to use some kind of time travel C debugger and do time travel on C level, then somehow restore the Python status - I don't believe any other path could be correct.

It's not useful for stdlib to have a prototype feature that works only on very trivial cases, so I would suggest to let it go. However, if you are super interested in this, feel free to build a 3rd party library - you can subclass pdb. If your project is actually working, it will attract a lot of users because that's what people have been dreaming of. Then pdb could follow your path :)

[the-osiris]

Thanks for the detailed explanation — that makes sense. I’ll drop the idea of proposing this as a stdlib feature, but I’m still interested in exploring what is possible at the Python layer for learning and experimentation. I may try building a third-party prototype using a pdb subclass, even if it only works for trivial or pure-Python cases. If it turns into something usable, great — otherwise it will still help me understand pdb and the tracing machinery better. ;)