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.
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?
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.
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.
Wouldn't it tremendously save developers time ?... And, accordingly, huge amounts of money ?
Please! No more sado-masochism!
There have been other similar tools previously, but they were either slow (chronicle), unable to work on complex programs or only worked on VMs.