“Undo Software today unveiled UndoDB – the first bidirectional debugger for compiled programs. A bidirectional debugger allows programmers to run a program backwards in time as well as forwards. The program can be stepped back line-by-line, or rewound to any point in its history. Furthermore, programmers can play the program forwards and backwards in a totally repeatable fashion, allowing them to ‘home in’ on the cause of a bug.”
I’ve never thought of doing something like this, but I think it’s a great idea. I’ll definitely have to try this out the next time I write a piece of (bad) code. Good stuff.
Huh. “first”? Guess they didn’t realize that CDC made the Cyber series of computers with “come-from” registers that could be used for traceback, or that entire operating systems were built around the idea of replayability in the 70s.
Of course, ‘deterministic’ and ‘multithreaded’ are antitheses.
But still, replay is nice if you’ve got it.
Hi. I’m one of the developers of UndoDB.
We are actually going to support threaded debugees in version 2 – it is possible to make a multithreaded programme run in a deterministic way. It’s a rather tricky thing to get right, but we have the general approach figured out and simple multi-threaded tests are passing in our development tree.
It is possible to make a multithreaded programme run in a deterministic way.
Yes, and a number of debugers have gone that route in the past. It’s a good route for a wide range of debugging, but it merely masks heisenbugs, rather than helping you find them.
>>It is possible to make a multithreaded programme run
>>in a deterministic way.
>It’s a good route for a wide range of debugging, but
>it merely masks heisenbugs, rather than helping you
>find them.
This is not necessarily the case. Making a multithreaded programme run in a deterministic way does not preclude triggering the really tricky bugs. For example, one could still have thread switches occuring at random points in a programme’s execution, such in-between reading two adjacent bytes of memory. The important requirement for a bidirectional debugger is that when it replays the programme, the thread switches occur in exactly the same place that they did when the programme’s execution was initially recorded. That’s what I meant by `deterministic’.
I.e. you still get to trigger the heisenbug, but you can then replay it exactly, as many times as you like.
ah, you don’t mean deterministic, you mean replayable. got it.
Having triggered the heisenbug, you can repeat it. However, making a small change to a program and then rerunning it may not re-trigger the heisenbug, so you can’t use the debugger to determine if the behavior is still reproducable. That would be deterministic.
Of course, the failure to reproduce a certain class of bugs does not make a debugger useless, it’s just a limitation you have to be aware of.
Green Hills Software (http://www.ghs.com) has had this functionality for quite some time in the TimeMachine debugger (http://www.ghs.com/products/timemachine.html)
If it’s based on gdb, which is GPL, don’t they have to release source? I didn’t see any obvious mention of such on their website.
Here you can see what you are looking for: http://undo-software.com/undodb_requestnoncommercial.html
…of this article which gave me the impression that this sort of things wasn’t generally possible with mainstream hardware:
http://www.kuro5hin.org/story/2003/9/8/14125/70302
The link you want is
http://undo-software.com/undodb_buy.html#GPL issues
(for the lazy ones, I’ll say that they claim to use smoe patches to gdb [which they make available] + another binary, not linked to gdb to do the grunt work)
because home computers can now easily transport you backwards in time by using something called a “debugger”.