3 ms·

Another aspect, where printf debugging can be better than debuggers are use-cases where timing is relevant. Some bugs don't occur when break points stop the pro

Another aspect, where printf debugging can be better than debuggers are use-cases where timing is relevant. Some bugs don't occur when break points stop the program at certain points in time. For completeness is should be added, that there are also cases where the printf can change the performance and make it impossible to find a bug. I think the two methods are complementary and should be use in combination. However, the big issue is that basic printf debugging is very simple to use and debuggers have a steeper learning curve in the beginning. Therefore, people start using printf debugging and don't invest into learning how to use debuggers. And when developers don't invest into learning how to use debuggers properly, they are missing the skills to utilize them and still use printf debugging in cases when debuggers are clearly superior.

spaetzleesser 6y ago
“ I think the two methods are complementary and should be use in combination” This should be repeated many times. I am getting very tired of the constant need of people who want to have a strict ideology and find the one true way of doing things.
maccard 6y ago
If you have a timing related issue fixed by a debugger it's probably going to be fixed by printing/logging too.
- majewsky 6y ago
  Not at all. Stepping through a function with a debugger usually takes on the order of seconds and minutes. Printing some stuff in the function usually takes on the order of microseconds or milliseconds. That's a difference of at least three, possibly eight or nine orders of magnitude. It's very easy to imagine a timing-related issue that's affected by a delay of X seconds, but not a delay of X microseconds (RPC calls are typically on the order of milliseconds, for instance).
SAI_Peregrinus 6y ago
Debuggers don't have to halt execution on hitting a breakpoint. They can do other things, like print the contents of memory, letting the host system handle the formatting. They're actually usually better for timing-sensitive prints than printf debugging. That said, most people don't know this is possible (the learning curve issue you mentioned), even though it's an important part of how to use debuggers!
- ShroudedNight 6y ago
  In my experience, GDB running commands on a breakpoint is generally much, much slower and more prone to materially changing the timing of things than printf.

spaetzleesser 6y ago

“ I think the two methods are complementary and should be use in combination” This should be repeated many times. I am getting very tired of the constant need of people who want to have a strict ideology and find the one true way of doing things.

maccard 6y ago

If you have a timing related issue fixed by a debugger it's probably going to be fixed by printing/logging too.

majewsky 6y ago
Not at all. Stepping through a function with a debugger usually takes on the order of seconds and minutes. Printing some stuff in the function usually takes on the order of microseconds or milliseconds. That's a difference of at least three, possibly eight or nine orders of magnitude. It's very easy to imagine a timing-related issue that's affected by a delay of X seconds, but not a delay of X microseconds (RPC calls are typically on the order of milliseconds, for instance).

SAI_Peregrinus 6y ago

Debuggers don't have to halt execution on hitting a breakpoint. They can do other things, like print the contents of memory, letting the host system handle the formatting. They're actually usually better for timing-sensitive prints than printf debugging. That said, most people don't know this is possible (the learning curve issue you mentioned), even though it's an important part of how to use debuggers!

ShroudedNight 6y ago
In my experience, GDB running commands on a breakpoint is generally much, much slower and more prone to materially changing the timing of things than printf.