Transition Watchpoints: Teaching Old Debuggers New Tricks

TL;DR

This paper introduces expression-transition watchpoints that leverage snapshots and binary search to improve reversible debugging, making it faster and adaptable across multiple programming environments.

Contribution

It presents a novel snapshot-based watchpoint technique that enhances reversible debugging efficiency and portability across different debuggers and programming languages.

Findings

Enables debugging of long-duration bugs with minimal overhead.

Requires only about 100 lines of code to implement for various debuggers.

Improves debugging speed for bugs occurring minutes after program start.

Abstract

Reversible debuggers and process replay have been developed at least since 1970. This vision enables one to execute backwards in time under a debugger. Two important problems in practice are that, first, current reversible debuggers are slow when reversing over long time periods, and, second, after building one reversible debugger, it is difficult to transfer that achievement to a new programming environment. The user observes a bug when arriving at an error. Searching backwards for the corresponding fault may require many reverse steps. Ultimately, the user prefers to write an expression that will transition to false upon arriving at the fault. The solution is an expression-transition watchpoint facility based on top of snapshots and record/replay. Expression-transition watch- points are implemented as binary search through the timeline of a program execution, while using the snapshots as landmarks within that timeline. This allows for debugging of subtle bugs that appear only after minutes or more of program execution. When a bug occurs within seconds of program startup, repeated debugging sessions suffice. Reversible debugging is preferred for bugs seen only after minutes. This architecture allows for an efficient and easy-to-write snapshot-based reversibe debugger on top of a conventional debugger. The validity of this approach was tested by developing four personalities (for GDB, MATLAB, Perl, and Python), with each personality typically requiring just 100 lines of code.