How does this compare with the tools mentioned here: http://stackoverflow.com/a/4561350/388928
Omniscient Debugging
11–20 of 21 posts
Re: Omniscient Debugging
#12The OCaml debugger also has time travel (http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual030.ht...).
Re: Omniscient Debugging
#13you don't have to wonder which threads ran when
How does that work? Does it really record every single assignment to every variable in every thread? Wouldn't that potentially slow everything down sufficiently that some classes of multithreaded bugs wouldn't show up under ODB?
Re: Omniscient Debugging
#14From the page: "Everybody loves it! They clearly understand the concept. They ask great questions, they make suggestions. But do they use it afterwards?? The ODB is as close to a silver bullet as you can get. Why don't people use it? I don't get it. :-(" "Needed More than anything else, I need people to use the ODB." Now, this tool is not for me personally - I don't see myself writing for JVM anytime soon - but it se…
I take a different standpoint than other people. I think that the problem is that debugging is a central task to people's work. They know the ins and outs of debugging with their current system. In order to switch to something new, they would need some guarantees, the most important being that the system will continue and improve for the foreseeable future. There is no point in learning a new system which will vanish in a few months. The leading indicator for this is the number of people who currently use the technology. Therefore, you have a chicken and an egg problem.
Re: Omniscient Debugging
#15Very cool. A C/C++ version (also mildly abandoned around the same time) was done by Robert O'Callahan, a very smart guy... Worth checking out and it would be nice if someone could pick it up and develop it more actively. http://code.google.com/p/chronomancer/
"The Chronicle framework provides complete register and memory-level recording of Linux processes and efficient queries over the recorded traces."
Wow, I was looking for something exactly like this a while ago, but was unable to find it. I notice that these days with Google it's really hard to find a tool or project when you're looking for it especially if it's more obscure. Might be a consequence of the ranking rules that crowd lesser known pages out.
Re: Omniscient Debugging
#16Interesting concept (one that i actually stumbled upon a couple of years ago).
If i would venture to guess why people don't use it more often i would say that it's because the marginal win (ease of debugging for a certain class of hard bugs) is smaller then the hassle of changing the complete toolset (current debugger and tools).
My guess this kind of tool is really good at a small class of hard bugs (which in general are pretty rare). For all the other the current tools are good enough so a switch would be costly for no immediate gain.
Re: Omniscient Debugging
#17From the page: "Everybody loves it! They clearly understand the concept. They ask great questions, they make suggestions. But do they use it afterwards?? The ODB is as close to a silver bullet as you can get. Why don't people use it? I don't get it. :-(" "Needed More than anything else, I need people to use the ODB." Now, this tool is not for me personally - I don't see myself writing for JVM anytime soon - but it se…
Well, I have used it, and it works, but I only use it in very specific cases. First of all, it's a bit of a bother to run; for one, it's not integrated with the IDE. So for bugs in simple areas of the code, I just don't bother and use the integrated debugger.
Then, the really hard problems (for me) usually involve a concurrency bug that manifests itself after a while. When ODB runs out of memory, it will discard the earlier part of the recording (it uses a circular buffer), and so I've found that some vital information is lost.
So I've found that ODB is great for complex algorithm bugs that are easy to reproduce in a controlled fashion. For other use-cases, it's either lacking in power or too much of a hassle.
Re: Omniscient Debugging
#18Try Chronon. While Omniscent is a research project, Chronon is a full blown product http://www.chrononsystems.com/
Re: Omniscient Debugging
#19There is an open-source (but Linux only) project called FReD which does reversible debugging for C and C++ programs: https://github.com/fred-dbg/fred
It works without modifying the program (e.g. no recompilation step necessary) or the debugger (like gdb).
Re: Omniscient Debugging
#20Very cool. A C/C++ version (also mildly abandoned around the same time) was done by Robert O'Callahan, a very smart guy... Worth checking out and it would be nice if someone could pick it up and develop it more actively. http://code.google.com/p/chronomancer/
"The Chronicle framework provides complete register and memory-level recording of Linux processes and efficient queries over the recorded traces." Wow, I was looking for something exactly like this a while ago, but was unable to find it. I notice that these days with Google it's really hard to find a tool or project when you're looking for it especially if it's more obscure. Might be a consequence of the ranking rule…
BTW I looked around a bit and found another similar system, based on QEMU instead of Valgrind, claiming to be faster, ie less runtime overhead while tracing, and also supporting kernel mode:
http://wiki.nss.cs.ubc.ca/Tralfamadore
Edit: never mind, the program does not seem to be publicly available, just papers