What if your debugger could go "go backwards
in time?" Would that make debugging easier?
By simply recording all variable assignments, it is possible to do essentially this.
This is the underlying idea for omniscient debugging.
The amazing part is that significantly large programs can be debugged in this fashion --
Ant, JUnit, the debugger itself.
Returning from rave reviews in Europe (Ecole des mines de Nantes,
INSA, ECOOP, AADEBUG, France! Sweden! Germany! Russia! Belgium!
Estonia!), the ODB made its next public appearence at OOPSLA where it
passed the $100 challenge (that was the amount offered for any bug it
couldn't find). Its presentation to thousands of screaming fans at JavaOne went
over with a blast! We (ODB & I) received the "Outstanding Talk" award. Yow! I later gave a
videotaped talk at Google.
Life is good
for the ODB and that's bad for bugs.
The debugger works by collecting "time stamps" which record everything
that happens in a program. A GUI then allows you to navigate
backwards in time to look at objects, variables, method calls, etc.
This means that you can see which values are bad, then find where those
values came from, who set them and why. This also means that there are no
non-deterministic problems. You don't have to guess where the problems might
be, you don't have to set breakpoints, you don't have to wonder which threads
ran when, you don't ever have to repeat a program
run. This is the debugger that you always dreamed about, but never thought was
Eclipse will launch the ODB from the RUN menu. [Import the ODB, set the main class to be com.lambda.Debugger.Debugger, and set the argument to be the program you want to run. (It's a bit lame, but simple. I am begging some folks for help with Eclipse.) I expect the same can be done for other IDEs.]
JDK1.5 works. You must select the correct version of the ODB now. ODB1.5 for JDK1.5 or ODB1.4 for JDK1.4.
As you may imagine, the 1.5 version is new and not well tested. I am putting out new releases modestly
Running the Demo
You may run the Web Start Demo by clicking on Web Start below and allowing its permissions request.
If you don't have Web Start, you can download debugger.jar (into ~/Debugger or c:\Debugger) and run it
by double-clicking on the jar file or running the jar file directly (java -jar debugger.jar).
Select "Demo" (a built-in pointer to a (buggy!) multithreaded quicksort). The program will run, then the debugger will popup and you will be able to "explore" the history of the program. Push the buttons, double-click on the objects.
You may select your own programs instead of the demo by defining some CSH aliases and calling debug:
% cd ~/Debugger
% jar xf debugger.jar aliases docs
% source aliases
% debug YourProgram
There is a full manual inside the .jar file (see docs/*), along with some Unix aliases (Microsoft .bat files) to make it easier.
The ODB is open source ala GNU. I have not made a major effort
to put its code on any of the open source repositories as it
does not currently seem the right thing to do. Just not
worth the effort.
More than anything else, I need people to use the ODB. I
need them to use it intensively and exclusively on a wide
range of programs. I need to talk with them and understand
how they see the model of the world that the ODB presents. I
need to experiment with different modes of interaction and
figure out what works best.
There is no reason to change the current version of the ODB
at all until I have enough information to make decisions.
I use it exclusively when developing Java code. In the past
year this included two heavy programming classes I
taught. We built our own version of BCEL, a complete web
framework (ala Spring) including a web server (ala Tomcat)
and a full battlefield simulation program (i.e., a *lot* of
code). I saw a lot of bugs*. I never resorted to another
I know what issues I encountered. Now I need to know what
other people encounter.