RevDB, a reverse debugger by Armin Rigo

RevDB is an experimental "reverse debugger" for Python, similar to UndoDB-GDB or LL for C. You run your program once, in "record" mode, producing a log file; once you get buggy behavior, you start the reverse-debugger on the log file. It gives an (improved) pdb-like experience, but it is replaying your program exactly as it ran---all input/outputs are replayed from the log file instead of being redone.

The main point is that you can then go backward as well as forward in time: from a situation that looks really buggy you can go back and discover how it came to be. You also get "watchpoints", which are very useful to find when things change. Watchpoints work both forward and backward.

I will show on small examples how you can use it, and also give an idea about how it works. It is based on PyPy, not CPython, so you need to ensure your program works on PyPy in the first place (but chances are that it does).

Transcript

1. RevDB, a Reverse Debugger Armin Rigo PyCon ZA 2016 October 2016 Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 1 / 18
2. Introduction I am Armin Rigo, part of the PyPy project since 13 years PyPy is another implementation of Python != CPython, but mostly compatible RevDB is a modified PyPy Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 2 / 18
3. What is a reverse debugger? Demo Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 3 / 18
4. How is that possible?? See later Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 4 / 18
5. Note I did not cheat It really works It really works for large programs Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 5 / 18
6. Recording & Replaying Demo Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 6 / 18
7. Main features Travel in time: next/bnext, step/bstep, continue/bcontinue, finish/bfinish p expression-or-statement watch expression using $0, $1, ... break function, break file:line Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 7 / 18
8. On more involved problems Write down what occurs at which time, because you’re going to go back and forth until you are lost See help for all commands Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 8 / 18
9. Completeness What works: Run any Python code that PyPy can also run Multithreaded apps CPython C extension modules Might get "Attempted to do I/O or access raw memory" in the debugger Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 9 / 18
10. Completeness What doesn’t works (so far?): Long-running programs Stackless/greenlet/gevent Track multiple processes Windows (for $?) Python 3 (soon?) Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 10 / 18
11. Comparison "Reverse debugging" == "Omniscient debugging" == "Historial debugging" == "Backwards debugging" for the C language: undodb-gdb, rr for Python (but not really the same thing): epdb, pode Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 11 / 18
12. Why not well-known? It is often a cannon to take down a fly Performance issues: unlike gdb and pdb, they slow down normal execution (with some of them, massively) (RevDB has the same issues) Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 12 / 18
13. Why not well-known? They tend to crash Not all give a full, reliable history: sometimes you need to guess if the debugger is telling you lies Often proprietary software with restrictive licenses (RevDB hopefully does not have these issues) Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 13 / 18
14. Sometimes you need the cannon In a very complex piece of code, likely you will hunt for a week for one bug I made RevDB in two months instead of spending one week tracking down a bug :-) Found the bug in one hour Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 14 / 18
15. Q & A https://bitbucket.org/pypy/revdb/ Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 15 / 18
16. How does it work? (slide 1/2) In PyPy, memory is naturally divided into "GC memory" and "raw memory" Recording: write in the log the result of: each C library call each raw memory read More recording: weakrefs, __del__ calls, thread switches, callbacks from C... (Done by tweaking RPython, the language in which PyPy is itself written) Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 16 / 18
17. How does it work? (slide 2/2) Replaying: read from the log the result of the same operations Everything else should be deterministic Illusion of going backward: fork is the key to go back, throw away the current fork, restart from an earlier fork, go forward again Armin Rigo (PyCon ZA 2016) RevDB, a reverse debugger October 2016 17 / 18