rr – record and replay debugger for C/C++ • Hacker News Board

Re: rr – record and replay debugger for C/C++

#131

Post by greg_law » Mon, Jul 22, 2024, 7:07 PM UTC

vchuravy wrote: post #62

laserbeam wrote: post #23

Is it truly only for C/C++? My limited understanding says a debugger needs: a list of symbols (.pdb files on windows, can't remember what they are on linux), understanding of syscalls and a few other similar things. I thought they don't care too much what generated the binaries they are debugging (obviously as long as it's native code). Doesn't rr work with other languages like rust, zig, odin, nim, and similar ones?…

We use RR a lot with Julia. It only gives you a GDB view of the system, but it can work with any interpreted or compiled language. Things that don't work are drivers that update mapped addresses directly. An example of this is CUDA in order to replay one would need to model the driver interactions (and that's even before you get to UVM) Another great thing is that RR records the process tree and so you can easily loo…

Shameless plug: https://undo.io does everything rr can but can also work with drivers that update the process memory (or unrecorded processes or even hardware). If you need that kind of advanced usage, check it out.

(Unlike rr it's not open source though - sorry! We have lots of programmes working on it full time and they insist on getting paid every month :)

Re: rr – record and replay debugger for C/C++

#132

Post by greg_law » Mon, Jul 22, 2024, 7:08 PM UTC

laserbeam wrote: post #30

leni536 wrote: post #26

Earlier quoted context omitted.

Interestingly gdb (and in turn rr) has some limited support for debugging python. At least you can get a python backtrace, but I didn't have success in setting pyhton breakpoints.

Yeah, 'cause you're technically debugging the python interpreter. I've had some success with tracing tools designed for C/C++ for a python project. Was not easy to set up and will obviously include frames from the interpreter. Tho, it feels wrong to expect a tool designed for native binaries to work well with python in this context. And that's ok. It feels lucky when it works as much as it does.

https://undo.io/resources/how-i-debug-python-code-with-a-tim...

"How I debug Python code with a Time Travel Debugger"

Works surprisingly well.

Re: rr – record and replay debugger for C/C++

#133

Post by _dain_ » Thu, Jul 25, 2024, 6:07 PM UTC

jvanderbot wrote: post #52

_dain_ wrote: post #13

Earlier quoted context omitted.

>If a certain piece of software is working well, what is the benefit of rewriting it in Rust? The "working" C program has a high risk of undiscovered bugs relating to concurrency and memory safety. Rust lets you rule out a large swathe of them by construction. Rust's type system is also far more expressive, which in many cases enables cleaner domain modelling.

You're correct that this is the stated justification most of the time. Should be nuanced though, because the working C program has a risk, but the the risk is a function of the size of the codebase, its age, and the number of audits it has undergone. It is definitely easier to write bugs in C due to the additional freedom you have, but it is not necessarily a "high" risk for mature C libraries. It is definitely not a…

Definitely. Once you aren't adding new features, the only thing left to do is fix bugs. New rewrites can make the same old mistakes. But there is the potential to have a lower "bug floor" in a safer language.

Re: rr – record and replay debugger for C/C++

#134

Post by roca » Fri, Jul 26, 2024, 11:20 PM UTC

ho_schi wrote: post #130

roca wrote: post #102

Earlier quoted context omitted.

Actually the gdb implementation predates rr, but (as an rr maintainer) I have to say that it is vastly inferior to rr. It's about 1000x slower than rr, and can't record across system calls or multiple threads or processes. It's so limited it's really a different feature.

Thanks. Can you explain why rr is so much more efficient?

The two approaches are completely different. gdb singlesteps the program and, before each instruction, records the state of registers and memory that will be changed by that instruction --- an undo log. Then you can reverse-execute an instruction by restoring the state from the undo log. This is incredibly slow because singlestepping requires a full context switch for each instruction executed.

rr, on the other hand, intercepts all system calls and other sources of nondeterminism but regular CPU instructions execute normally with no overhead. The details about rr are here: https://arxiv.org/abs/1705.05937