How do Time Travel Debuggers Work? - Design and Implementation of a Time Travel Debugger
summary
Compares three real systems — rr, TTD, and Undo.io — and shows a live Doom recording that replays a process by capturing an event log plus occasional snapshots so any memory or register state can be inspected. rr relies on hardware perf counters, Undo.io uses JIT binary translation, and TTD records more memory reads to support parallel recording; typical overhead is about 1–5x slowdown. Threads serialize on replay so most races reproduce, shared memory and some CPU instructions remain tricky, but recordings are portable and debuggable offline.
AI-written summary · about
chapters (9)
- 0:00Demo and introduction
- 14:04Time travel solutions overview
- 19:12Design decision 1: Re-execution
- 30:30Design decision 2: Process boundary
- 34:57Design decision 3: Tracking time
- 38:33Instrumentation techniques
- 47:55Design decision 4: Memory determinism
- 56:58Comparison and summary
- 1:10:20Final soapbox and QA
related talks
42mTime Travel Debugging - It’s Time to Debug Different
58mTime Travel Debugging - Debug Complex C++ Bugs With Software from Undo
57mModern Linux C++ debugging tools - under the covers
01h 29mModern Linux C++ Debugging Tools - Under the Covers
20mHow Debuggers Work
15mGive me 15 minutes & I'll change your view of GDB
31mRace Conditions - Practical Tools & Techniques for Testing, Preventing, and Debugging C++/C Code
01h 27mBecome a GDB Power User