Normally, when you want to debug software, you use a tool to pause execution in order to step through the code line by line. That’s after you’ve been able to isolate the bug. The problem is that for bugs that exist in complex systems, isolating the bug can be tricky. Some bugs are difficult to reproduce, because they don’t produce substantial effects, making them hard to pin down. For example, logic errors can produce slightly unexpected results that add up over time. Tracking the source of the error by logging input and outputs can be painstaking.
If a developer could only look back in time to see the events that led up to the failure, they might be able to save time, thereby saving a company money. That’s the hypothetical that time travel debuggers put out. According to UndoDB, reverse debugging or time travel debuggers “can deliver significant savings. Mentor Graphics has reduced debugging time by 66% (two thirds) after implementing Undo’s reverse debugger for Linux, UndoDB. Take an average software developer earning $90,000. Currently they spend a quarter of their time debugging, costing $22,500 in wages. Reducing that by two thirds, creates a saving of $15,000 and increasing available developer time.”
Time travel debuggers have been available for GDB compatible programming languages like C/C++, Go, Fortran, Pascal, etc.
Then, you have projects like…
- Chronon for Java
- RevDeBug for .Net and C#
- RevPDB for Python
- Elm TTD for, as you can guess, Elm
Here are some of the features that are currently stable:
- Ability to step back in code
- Rewind to a set breakpoint
- A timeline with record and replay markers, current position in time indicator, errors/messages
- Retroactive console logging
Of all the stable features, retroactive console logging is the most interesting in that a large portion of front end debugging is looking at output logged to a browser’s console. How many times have you had to dig back into the source files to move console logs around to further isolate a bug? Countless times most likely. According to Mozilla, this headache is alleviated with Web Replay.
“The bug only needs to be reproduced in a recording tab once, and then console logs can be added which apply throughout the entire recording. This is based on the log points feature in the debugger, which can be enabled with the devtools.debugger.features.log-points preference. Set a breakpoint and right click on it to change it to a log point.
In a non-recording tab this will update the console whenever the log point’s location executes in the future. In a recording tab, however, this will update the console with messages for every time the location has ever been hit. This requires scanning the recording and the console will not update immediately. These messages will show up on the timeline and can be sought in the same way as other console messages.”
There are several features that are still being worked on. Some of them are:
- DOM/CSS integration
- Object watching(logging changes to object over time)
- Bookmarking points in recording
- code path highlighting
- Comparing executions(buggy vs clean code)
Web Replay may change the way front end developers code, but the complexity of time travel debuggers may limit its scope. Will developers accustomed to Chrome migrate to Firefox to take advantage of the new technology? If so, Google may also create a time travel debugger of their own. On the other hand, if the demand for time travel debuggers is minimal, the cost of developing such a complex tool may not be worth it to Google. Only time will tell whether Mozilla’s project will bear fruit.