[celticjames]

The stories in the post all have repeatable bug conditions. If you read bugs submitted for something like Chrome or Firefox (or any big complex program) you see a lot of trying to figure out what state triggers a bug. There's a lot of, "I can't repeat it. Works fine for me." It's almost impossible to deduce what causes a bug because so many possible states can exists at any given moment.

The way a lot of bugs are eventually solved is not by asking what caused them, but when they started. It's often the regression testers who find the source. You keep going back through the nightly releases until you find one that doesn't exhibit the bug. At that point you go to the commit logs and there is your problem.

[mattmanser]

I've half a blog post written about this that I'll probably never finish.

Given how much memory, disk space, etc. we have these days it's getting to the point that we should really have the ability to dump a program's state and all actions from starting the program to finishing it and then fast forward/rewind the actions of the user. Inspect all the locals, see what's actually happening. Set a loop over 30 seconds. Bugs would be a lot easier to find and recreate.

A bit like lightbox, but for debuggers!

It's just that no-one's done it yet and no programming language is really written to do it.

[jefffoster]

Isn't this what omniscient debugging is? http://www.lambdacs.com/debugger/

Great quote from that page, "The ODB is as close to a silver bullet as you can get. Why don't people use it?"

[dunham]

Last I checked, OCaml had a replay debugger -- one which lets you step backwards.

And I know the mozilla guys sometimes use chronicle-recorder to fully record a running application for debugging. (It was referenced in a bug I filed.)

  http://code.google.com/p/chronicle-recorder/

[dlo]

Does anyone have experience using Chronon?

http://chrononsystems.com/

It is billed as "DVR for Java."

[seanmcdirmid]

> Given how much memory, disk space, etc. we have these days it's getting to the point that we should really have the ability to dump a program's state and all actions from starting the program to finishing it and then fast forward/rewind the actions of the user.

Given a program from 20 years ago this is definitely possible. Given a program from today, it becomes an intractable problem quite quickly.

> It's just that no-one's done it yet and no programming language is really written to do it.

Live programming might get you what you want, but it won't be through brute force tracing of everything. Better to focus on deterministic replay then its quite easy to rebuild the contexts we need to fake it.

[stiff]

Bisecting the code is a pain in the ass. Until back-in-time debugging is more of a standard, another alternative is simply to log a lot of stuff and include a bug reporting tool in whatever software you ship that will attach the log to the bug report.

[greenyoda]

The problem with logs is that programmers log the data that they believed, at the time they wrote the code, would be useful to help diagnose problems. However, many bugs arise from conditions that programmers failed to anticipate, and thus may have failed to log.

Also, there are important things that you just can't log for legal or ethical reasons. For example, no user of a browser would be happy to know that the current URL they were viewing or their POST data was sent back to a browser developer (or even saved in a local file) without their explicit permission.