4 ms·

I'm 100% in the camp that print statements are terrible for debugging, and I never use them as a debugging tool for my personal projects or on my local box. How

I'm 100% in the camp that print statements are terrible for debugging, and I never use them as a debugging tool for my personal projects or on my local box. However here is why, despite something like gdb/rr being the best tool for the job, I fallback to print statements for most code that's shared beyond my personal scope: - Works in any programming language. - Works in programming languages that aren't easy to debug with gdb out of the box without setup. - Works if you're trying to figure out why a problem is occurring without a core dump - Other developers understand how it works -- I find that there's no reasonable expectation that a developer knows how to use gdb. - Works on systems you only have log access to -- true for production systems that have sensitive customer data. So instead of debugging in two different ways, I've submitted myself to print statements -- tragedy of the commons I guess.

anovikov 5y ago
Add one big thing: log debugging is convenient when debugging something with concurrency. When stopping on a breakpoint isn't an option.
- db48x 5y ago
  You 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 5y ago
    My 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 5y ago
      Sometimes 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.

anovikov 5y ago

Add one big thing: log debugging is convenient when debugging something with concurrency. When stopping on a breakpoint isn't an option.

db48x 5y ago
You 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 5y ago
  My 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 5y ago
    Sometimes 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.