Hacker News Reader

Comment by neves | Hacker News Reader

I've never heard about rr http://rr-project.org/), his tool to record program execution and debug it afterwards. The alleged 1.2x slowdown in execution is negligible. The ability to reverse in time is almost a nirvana. I'm sad I didn't have it when I used to program C++. Hope he succeeds in his new endeavor. We'd all win big.

Does anyone knows of similar tools for Python and in-browser Javascript?

View on HN

Mozilla is prototyping a feature called "WebReplay" to support reverse-debugging of JavaScript and DOM mutation:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...

https://bugzilla.mozilla.org/show_bug.cgi?id=1207696

It looks like Microsoft is implementing a similar time-travel feature in Chakra:

https://github.com/Microsoft/ChakraCore/commits/TimeTravelDe...

For Python my coworker (and friend) Tom has a great project called timetravelpdb: http://everythingsysadmin.com/2014/04/time-travel-pdb.html explains a bit on it, the repo is https://github.com/TomOnTime/timetravelpdb

Basically it's an extension of pdb that allows you to jump back and forth in time.

Re: Javascript - If you use the'redux' (http://redux.js.org/) framework you can get something like this (https://github.com/gaearon/redux-devtools-dock-monitor)

I understand you never claimed they are similar. But to be fair (and with due credit to redux for being a great framework), all redux does is save method call arguments in an array. rr is on a different scale altogether.

I was really impressed when finding out about Microsoft's Chakra JS engine Time travelling debugger[1], I think that's what you're looking for, haven't tried it myself though.

[1] https://youtu.be/1bfDB3YPHFI?t=304

If I'm understanding this correctly, then Java has had it for ages now via the "Chronon" debugger. It's the only reason why I pay for an IntelliJ Ultimate Edition license, since it comes bundled.

There are other reversible debuggers, but even a mature one like Chronon has more overhead than this. 1.2x is basically nothing.

Not if you have > 1 busy thread.

No exactly the same thing but Tonic has similar capabilities using CRIU (checkpoint and restore in user space) for Javascript time traveling: http://blog.tonicdev.com/2015/09/10/time-traveling-in-node.j...

It's an interesting different approach because it allows you to rewind the entire machine, so you can interact with interactions between different processes, etc (happy to answer questions, I am a dev on it)

If you're willing to accept things that compile to in-browser javascript, check out Elm's magical time-traveling debugger: http://debug.elm-lang.org/

I'm building something like this for in-browser Javascript, but in a larger context. We're not ready for public consumption yet, but: https://fabric.fm

Interesting! Tried to subscribe but got an error: {"code":-5000}

the python case is interesting ... after all, the interpreter is just another binary executable. perhaps there's a way to write a layer above rr to "step" in Python code rather than the underlying C code. same with JS (Node.js) or any other language run-time.

Seems rr is using fork for its implementation. The first time I've seen this approach taken is in Ocaml's debugger.[1]

[1] http://caml.inria.fr/pub/docs/manual-ocaml/debugger.html

Sounds very similar Green Hills Software's TimeMachine for embedded applications.

TimeMachine needs a specialized hardware probe connected via JTAG, if I'm not mistaken. The probe is powerful enough to record everything (registers, operations, etc) in its memory without affecting the embedded device. Then you can replay the info however you want, in as much detail as you like.

The feature here is more like software emulation, and it will really allow you to take the instruction pointer in reverse direction. Unlike TimeMachine which records in real time and let's you browse the recorded data as you wish, but after execution has occurred.

My thoughts were very similar to yours. In 1992, when I started out in embedded on a Philips 8051 and debugging it was via an ICE and had direct visibility and control of the 8051.

The ICE would be connected to a bonded out version of the 8051 and I was almost able to capture every single clock cycle of 8051's execution. When I hit a failure, I would just replay the trace and see what went wrong.

It looks like the folks on the big machines have caught up :-)

I had access to a Huntsville Microsystems ICe that used a bog-standard - non-bonded-out - 68008 in harness. I had scripting tools that would capture and replay all the registers to back the machine up.

That HMI was a brilliant machine.

It's really the last debug tool I ever used besides AVR, PIC and one ARM JTAG for doing BSP work.

Python and in-browser Javascript are also programs, in theory rr covers the entirety? But I don't know what the ergonomics are like (e.g., how much will you see program activity in your platform that you don't care about, and how well can you see the activity in the code you are debugging?)

Yes, rr can record python and JS execution just fine, but the debugging experience is hopeless, since right now rr just gives you gdb. With an astounding tolerance for pain you can make progress by calling JS engine functions from gdb, but nobody wants that.

This is fixable, however, and on my agenda.

There is something similar in bpython called rewind. Run a few commands in the repl and then try `ctrl+r`.

I wonder how it works. Assuming it must capture state at t=n, and somehow calculate the diff to get to t=n+1. Could theoretically pop diffs to get to any point in the past.

Its not free, but there is http://undo-software.com/undodb/

Gdb has supported reverse debugging since 2009.

I've used it, and I've been using rr. gdb's reverse debugging was useful to me a few times, in extremely limited situations.

I often do my initial runs under rr, just in case I might want to debug, because it's useful most of the time and it's not enough overhead to worry about.

gdb's reverse debugging works after you narrow the range of interest down to a very small region, because otherwise its buffer will repeatedly overflow and it'll take ages.

Reply on news.ycombinator.com