That's correct. Anything you can debug with gdb should be debuggable under rr. (Though of course there could always be rr bugs that need to be fixed.)
Languages where debugging requires complex VM services are another story. For example, if your language supports debugging by modifying the code generated by a JIT, that's going to be a problem under rr, since an rr replay preserves the exact instructions executed during recording.
Debugging a non-trivial application with gdb without gdb crashing is quite a feat, however. Hopefully rr is less prone to segfaulting. Gdb is easily the least stable standard debugger I've used on any preemptive scheduling OS.
Looks like it's because until now it was not available, since rr has gained both reverse execution and x86-64 support quite recently (now and end of 2014 respectively)
There have been other similar tools previously, but they were either slow (chronicle), unable to work on complex programs or only worked on VMs.
The features and general approach are quite similar.
There are some significant internal differences. UndoDB relies on code instrumentation but rr does not. Mainly because of that (AFAIK), UndoDB's recording overhead is significantly higher than rr's. On the other hand, UndoDB can handle some cases rr does not, in particular when a recorded task shares memory with another task which is not part of the recording. Also, UndoDB supports ARM/Android and rr does not.
Awesome. I wanted just something like that but never heard it exists. Thanks, HN.
Anyone with experience using rr - does it work for long-running processes (daemons) that eventually crash? I had few cases where it wasn't possible to trigger a failure right away, and waiting another day for the daemon to crash to have a new core dump wasn't any great experience. Is the tool usable for such cases - I mean, without dumping few hundred gigabytes of execution history?
The recording data rate is highly workload-dependent. For Firefox I find it's often around 1MB per second but your daemon could be a lot more or less than that, depending on what it does.
A few hundred gigabytes may sound like a lot, but it costs less than $100 so if it saves you a significant amount of time, why not? The biggest problem using rr with a very long trace is that to debug it you need to replay all the way forward to the crash point, which might take you another day or longer. Though that's just machine time so you can run that in the background while doing other work.
How much of rr is C++-specific? I know of a few other compiled languages out there that would love to have a tool like this.
As I understand it, not much. It seems to work fine with Rust, for instance.
That's correct. Anything you can debug with gdb should be debuggable under rr. (Though of course there could always be rr bugs that need to be fixed.)
Languages where debugging requires complex VM services are another story. For example, if your language supports debugging by modifying the code generated by a JIT, that's going to be a problem under rr, since an rr replay preserves the exact instructions executed during recording.
Debugging a non-trivial application with gdb without gdb crashing is quite a feat, however. Hopefully rr is less prone to segfaulting. Gdb is easily the least stable standard debugger I've used on any preemptive scheduling OS.
gdb almost never crashes for me debugging Firefox on Linux, with or without rr.
Why such/similar tool with a simple GUI interface isn't default standard, for most popular languages/platforms ?
Wouldn't it tremendously save developers time ?... And, accordingly, huge amounts of money ?
Please! No more sado-masochism!
Looks like it's because until now it was not available, since rr has gained both reverse execution and x86-64 support quite recently (now and end of 2014 respectively)
There have been other similar tools previously, but they were either slow (chronicle), unable to work on complex programs or only worked on VMs.
Anyone know how rr compares feature wise with http://undo-software.com?
The features and general approach are quite similar.
There are some significant internal differences. UndoDB relies on code instrumentation but rr does not. Mainly because of that (AFAIK), UndoDB's recording overhead is significantly higher than rr's. On the other hand, UndoDB can handle some cases rr does not, in particular when a recorded task shares memory with another task which is not part of the recording. Also, UndoDB supports ARM/Android and rr does not.
Awesome. I wanted just something like that but never heard it exists. Thanks, HN.
Anyone with experience using rr - does it work for long-running processes (daemons) that eventually crash? I had few cases where it wasn't possible to trigger a failure right away, and waiting another day for the daemon to crash to have a new core dump wasn't any great experience. Is the tool usable for such cases - I mean, without dumping few hundred gigabytes of execution history?
The recording data rate is highly workload-dependent. For Firefox I find it's often around 1MB per second but your daemon could be a lot more or less than that, depending on what it does.
A few hundred gigabytes may sound like a lot, but it costs less than $100 so if it saves you a significant amount of time, why not? The biggest problem using rr with a very long trace is that to debug it you need to replay all the way forward to the crash point, which might take you another day or longer. Though that's just machine time so you can run that in the background while doing other work.