3 ms·

He writes « Perhaps people equate "debugging" with "using an interactive debugger" » I think it's useful to think of two independent 'axes' of debugging: - si

He writes « Perhaps people equate "debugging" with "using an interactive debugger" » I think it's useful to think of two independent 'axes' of debugging: - single-stepping vs reading traces - using specialist debugging software vs modifying the code Most of the time I much prefer reading traces, and IDEs often have decent primitives for setting sophisticated tracepoints, but the UI support for them is often very weak (while adding a breakpoint might be a single key press). So I've often found myself using 'printf'-style debugging because (until compile times get very long) it's more ergonomic then using the debugger's tracepoints. I haven't tried rr yet. Does anyone know how good it is at this? I'd like to be able to do things like define a keypress for a given tracepoint and toggle its output on and off while I'm scrolling through a trace.

abhishekjha 8y ago
> using 'printf'-style debugging And the horror that descends upon you once you commit+push those statements.
- pjc50 8y ago
  Either "don't do that then" or have a logging framework that lets you leave enough printf in to diagnose crashes in the field.
  - abhishekjha 8y ago
    I used to debug using print statements earlier and that was because we were not allowed to use any IDE. Now that I know hoe to use IDEs properly, things have been better. And there is always logging and `git diff` to help you out. Those colouring schemes really come handy.
- Vinnl 8y ago
  A pre-commit hook can prevent that for you. (I use a linter that will only allow log statements if they're preceded by an exception comment, which I will only add if I actually intend to log things.)
- JustSomeNobody 8y ago
  what I do in the situation where I have had to track down a really elusive bug and chased it around the code with print statements is checkout a fresh copy of the code and only merge in my fix.
- taneq 8y ago
  Do you people not read through your changes before checking in? I mean, it's better to buddy check-ins but even rubber-ducking through the changes will catch a ton of mistakes.
- coldtea 8y ago
  What horror? At best it might be a slight embarrassment (that can be avoided by checking the diff before commit). Then again, having killed the bug is more important than pretty commits.
- jpindar 8y ago
  Doesn't happen to me. My printfs start like this: if (debugLevel != 0) printf(.... Sometimes the condition compares debugLevel to some other value, but it will never print if debugLevel is zero, and its going to be zero unless I set it to something else.
ensiferum 8y ago
This pertains only to C and C++ but the problem with printf type debugging is it might throw you off. Consider: int* foo = .... ... *foo = 123; printf("killroy was here"); Now that code could actually print "killroy was here" but also crash on the pointer dereference. When this happens a naive developer will be thinking that the foo ptr access can't be the problem.
- mjw1007 8y ago
  Alas, the same problem has been known to happen with debugger-provided breakpoints and tracepoints. That's why GCC advertises -O0 as «make debugging produce the expected results» (which in practice will avoid the problem in your example too). There are lots of other ways to cause yourself trouble using printf to debug, of course (eg clobbering errno).

abhishekjha 8y ago

> using 'printf'-style debugging And the horror that descends upon you once you commit+push those statements.

pjc50 8y ago
Either "don't do that then" or have a logging framework that lets you leave enough printf in to diagnose crashes in the field.
- abhishekjha 8y ago
  I used to debug using print statements earlier and that was because we were not allowed to use any IDE. Now that I know hoe to use IDEs properly, things have been better. And there is always logging and `git diff` to help you out. Those colouring schemes really come handy.
Vinnl 8y ago
A pre-commit hook can prevent that for you. (I use a linter that will only allow log statements if they're preceded by an exception comment, which I will only add if I actually intend to log things.)
JustSomeNobody 8y ago
what I do in the situation where I have had to track down a really elusive bug and chased it around the code with print statements is checkout a fresh copy of the code and only merge in my fix.
taneq 8y ago
Do you people not read through your changes before checking in? I mean, it's better to buddy check-ins but even rubber-ducking through the changes will catch a ton of mistakes.
coldtea 8y ago
What horror? At best it might be a slight embarrassment (that can be avoided by checking the diff before commit). Then again, having killed the bug is more important than pretty commits.
jpindar 8y ago
Doesn't happen to me. My printfs start like this: if (debugLevel != 0) printf(.... Sometimes the condition compares debugLevel to some other value, but it will never print if debugLevel is zero, and its going to be zero unless I set it to something else.

ensiferum 8y ago

This pertains only to C and C++ but the problem with printf type debugging is it might throw you off. Consider: int* foo = .... ... *foo = 123; printf("killroy was here"); Now that code could actually print "killroy was here" but also crash on the pointer dereference. When this happens a naive developer will be thinking that the foo ptr access can't be the problem.

mjw1007 8y ago
Alas, the same problem has been known to happen with debugger-provided breakpoints and tracepoints. That's why GCC advertises -O0 as «make debugging produce the expected results» (which in practice will avoid the problem in your example too). There are lots of other ways to cause yourself trouble using printf to debug, of course (eg clobbering errno).