3 ms·
Add one big thing: log debugging is convenient when debugging something with concurrency. When stopping on a breakpoint isn't an option.
by anovikov 6y ago
Add one big thing: log debugging is convenient when debugging something with concurrency. When stopping on a breakpoint isn't an option.
- db48x 6y agoYou really should try recording with RR; you can play the recording back afterwards, stopping anywhere you want and resuming execution or even running the program backwards to go back to something you missed the first time. You can record it on the server and replay it on your laptop. You can record your tests and send recordings of your test failures to your bug tracker for efficient bug fixing.
- jcranmer 6y agoMy recollection, though, is that RR can only do single-core debugging, and it doesn't help with issues that involve multiple cores stomping on each other in multiple threads.
- db48x 6y agoSometimes that’s true, though you’ve stated it imprecisely. RR emulates pthreads in userspace, converting your multithreaded programs to run in a single thread. It does context switching between your threads much as the OS would if you had only one CPU core, but there is no true concurrency. This can hide some problems that are the result of race conditions, making them never show up in any of your recordings. If the problem doesn’t show up in any recordings, then RR isn’t going to help you debug them. However, RR does have a mitigation for this, called chaos mode. In chaos mode it doesn’t schedule your threads fairly. It randomly starves some threads, not allowing them to be scheduled, or interrupts them before their usual time slice is up. This can make it easier to capture race conditions in a recording, though it isn’t perfect. You should give it a try some time.