Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rr-project.org

Post reply on HN
Print view View original

121–130 of 134 posts

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

#121

Post by kragen »

throwaway2037 wrote: post #113
dima55 wrote: post #96

Earlier quoted context omitted.

If you want to mention this, then you very clearly haven't actually tried it. The implementation in GDB is more convenient than rr (you can start/stop recording at will), but it is also orders of magnitude less efficient. It's only usable for very small code snippets. Otherwise it takes effectively forever and/or runs out of resources.

> runs out of resources RAM? What kind of dev box runs out of RAM in 2024? I built a 64GB RAM dev box during COVID-19 crisis. I have never once come close to using all that RAM, even with a squillion Chrome tabs open. Still, thank you to share your first-hand experience. Did you ask the GDB Dev team for any feedback on the slow performance?

gdb record and replay will absolutely eat up your piddly 64 gigs of ram in a few minutes if you just let it loose. it will eat your 12-terabyte hard disk too, it just takes a little longer. the gdb manual has many helpful tips for how to allocate your ram carefully to record and replay, as well as using a disk buffer instead of recording to ram, so the gdb dev team is already well aware of the problem

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

#122

Post by kragen »

throwaway2037 wrote: post #118
tialaramex wrote: post #49

Earlier quoted context omitted.

This isn't really true. Rust has a much better type system. When writing generic code the impact is enormous. C++ doesn't have a real Empty Type, and it thinks Units have non-zero size. In practical terms this makes it incredibly wasteful and in terms of a clear abstraction it encourages you to come up with a hack that's unclear but efficient.

Can you instantiate an empty type? If yes, are all instances unique? Years ago, I was surprised to learn how C++ handles the (essentially) empty type (no data): A single byte to differentiate each instance.

that's unit. the empty type is a type you cannot instantiate

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

#124

Post by vinnyvichy »

whatsakandr wrote: post #41

I've used rr very sucessfully for reverse engineering a large code base using a break on variable change combined with reverse-continue. Took the time to extract critical logic way down.

May I assume the large codebase was written in a language with (for lack of a better term) dynamic types?

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

#125

Post by alfiedotwtf »

[off-topic] does anyone here who regularly uses a debugger (even just breakpoints and watchers in their IDE) use it for async execution? I've never tried, but I'm just trying to think how all that jumping around the executor and any runtime would work (if at all).

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

#126

Post by nesarkvechnep »

vinnyvichy wrote: post #124
whatsakandr wrote: post #41

I've used rr very sucessfully for reverse engineering a large code base using a break on variable change combined with reverse-continue. Took the time to extract critical logic way down.

May I assume the large codebase was written in a language with (for lack of a better term) dynamic types?

No, you may not.

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

#127

Post by MaskRay »

I almost use rr every day, along with a gdb frontend: cgdb.

rr record /tmp/Debug/bin/llvm-mc a.s && rr replay -d cgdb

I've have success story with some bugs only reproducible with LTO. Without rr it would be a significant challenge.

It would be nice if Linux kernel could be debugged with rr. Does anyone have success with kernel under rr+qemu ? :)

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

#128

Post by rapiz »

MaskRay wrote: post #127

I almost use rr every day, along with a gdb frontend: cgdb. rr record /tmp/Debug/bin/llvm-mc a.s && rr replay -d cgdb I've have success story with some bugs only reproducible with LTO. Without rr it would be a significant challenge. It would be nice if Linux kernel could be debugged with rr. Does anyone have success with kernel under rr+qemu ? :)

what's the benefit of using cgdb while you can use gdb layout src?

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

#129

Post by ho_schi »

Veserv wrote: post #104
29athrowaway wrote: post #100

Earlier quoted context omitted.

rr predates the one in gdb if I am not mistaken

rr was introduced in 2014 [1]. gdb reverse debugging was introduced in 2009 [2]. You can see a fairly comprehensive history of time travel debugging here [3]. Not to say the built-in gdb reverse debugging was any good. It had (has?) like 1,000,000% overhead which is basically unusable. At least some implementations in the history that were introduced earlier only had ~1,000% overhead or less in general. Yes, a litera…

Thanks for the info and links :)

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

#130

Post by ho_schi »

roca wrote: post #102
29athrowaway wrote: post #100

Earlier quoted context omitted.

rr predates the one in gdb if I am not mistaken

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?
Post reply on HN