Time Machine as a Debugger
I’ve had a couple of articles open to remind me to blog about them for a while now – one from Tim Bray’s Android Diary and a response to it from Nick Kew. The key part of Tim’s post:
At a deep level, debugging with print statements is superior to all other approaches. Which is good, because we seem to be stuck with it.
Firstly, I’m very strongly against debugging via System.err.println – you should have a logging system in place instead and just add extra messages to that. That way if you accidentally check them in, at least they go to the logs and are hidden at DEBUG level rather than annoying everyone all the time by going to System.err.
Apart from that minor quibble though, I’m a big fan of the println debugging camp. I just never found debuggers to be particularly useful. In thinking about this I think I’ve really struck on the key problem I have with debuggers and a really neat solution.
The key problem I have is that when you’re in the middle of a debugging session it’s really hard to keep track of where you’re up to and what the state is and whether you want to step over or into this particularly function. If you accidentally step over a function you meant to step into you have to go back and start all over again because the step backwards button, if available at all, is generally pretty useless. On the other hand, if you just print a bunch of stuff out, you can easily scroll back and forth through the output at your leisure to understand what’s going on. The debugger is like keyhole surgery – very accurate but very limited view. The println approach is like a MRI – much more of a general view, but you may not be seeing the entire picture. Fortunately, with println you get to decide which bits you see and which you don’t as you can always print out more data.
The solution is to change the debugger from something that lets you view the problem as it’s running, to something that records the program as it runs then lets you watch a replay. I’m imagining something like the Time Machine interface, where you can scroll back and forwards through time and see what the call stack was and what the value of variables were at that point in time. Matching it up with a screen recording (and/or console output recording) would let you see what you were doing at that point as well.
While I’m sure it would significantly impact performance to record all this detail as the program is run, it would be incredibly useful – just reproduce the bug once and then roll back and forward over it as many times as you want, with all the detailed information you want, until you identify what the problem is.
How is it that I’ve never heard of something like this before? It seems so obvious…
January 19th, 2009 at 11:59 pm
There’s been some work done on this, but I’ve never seen it get beyond research stage. Presumably something could be done with btrace, but it’s probably Quite Heavy(c)(r). Would be highly useful though.
Google has some papers, mostly from IBM and friends.
January 20th, 2009 at 12:10 am
VMWare supports that (see http://www.replaydebugging.com/) and there are also a few other debuggers out there that use snaphots of the entire program state to allow stepping backwards. I’m just waiting for such features to become available in Eclipse. :-)
January 20th, 2009 at 12:20 am
For Java, there are both open and closed source implementations of the core of this concept.
http://www.google.com/search?q=omniscient+debugging
As far as I know, there aren’t any available as IDE plugins, or with reasonably good user interfaces.
January 20th, 2009 at 12:27 am
See, I knew other people should have had this idea before. I’m surprised it hasn’t gone mainstream though. The VMWare based option looks reasonably polished but since it’s tied to Visual Studio isn’t going to be any use for me. I would have expected at least one of the solutions to use DTrace – it seems right up it’s alley, though I’m more familiar with the hype of DTrace than the actual technology.
January 20th, 2009 at 2:58 am
Seems to me there are two startingpoints: the classic debugger and the trace. In the case of the former, the interactivity is great, but you also want features like session recording and playback, and rollback. AFAICT the Usual Suspects (like gdb) are working in that direction. In the latter case, the challenge is to present you with the information you need in a digestible form without total overload, and the leading solution appears to be Dtrace.
FWIW, when I insert my own prints in anything more than a throwaway test prog, I always make them something I can define out (C preprocessor), or at worst replace by a stub (languages with no such facility).