Omniscient Debugging
"Because the Debugger Knows Everything"
18 February 2007

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 possible.

One page description of the ODB AADEBUG paper on Omniscient Debugging (pdf)
ODB User Manual

Changes to Newest Version

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 regularly.

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 current distributions are here: Release Page




Maven

com.neuronrobotics LewisOmniscientDebugger 1.6



Gradle

compile group: 'com.neuronrobotics', name: 'LewisOmniscientDebugger', version: '1.6'

A Better Mousetrap

Open Source

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.

Needed

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 debugger.

I know what issues I encountered. Now I need to know what other people encounter.

Bil Lewis
Bil@LambdaCS.com



========================================================

* My style of programming has changed since the ODB. I now write insanely fast, making numerous mistakes. This gives me something to search for with the ODB. It's *fun*.