4 ms·

Sometimes the print statement is the best tool for the job; sometimes it is the only tool for the job. If you know how to debug by adding print statements, runn

Sometimes the print statement is the best tool for the job; sometimes it is the only tool for the job. If you know how to debug by adding print statements, running a test, and reading the resulting log, you can solve any problem, in any environment, on any platform[1]. Other tools may well provide faster results in specific situations, but one has to balance the time spent learning & managing fancier tools versus the time spent getting the job done. 1) Well, okay, there are exceptions. Perhaps you have to find a spare IO pin attached to an LED, and make it blink at you in morse code, because your serial port hasn't come up yet, so you can't print to the console; but it's the same idea.

rurban 4y ago
- boardwaalk 4y ago
  That's a high horse you've got there. There is a vast class of bugs that are not memory bugs and many languages where memory bugs are just not an issue.
  - hgomersall 4y ago
    Not only that, but the bugs I find most difficult to deal with (like races) I find have a tendency to disappear in a debugger. Tracing output is what's needed here, and that's just a slightly more structured print.
  - userbinator 4y ago
    I have debugged plenty of memory bugs without using a debugger. Debugging multithreaded/async code is an entirely deeper level of hell, and there's been plenty of times where just having a debugger attached was enough to make the code work, or building unoptimised/with debugging information. On the other hand, carefully placed prints can catch the culprit without affecting the timing so much that the bug disappears.
- Cerium 4y ago
  I have hunted plenty of bugs that only show up when the debugger is not connected to the target.
- eurasiantiger 4y ago
  I’d like to see you debug a database migration with a runtime debugger. The issue starts after about two million entries and only affects a subset of them. Have fun!
  - hamburglar 4y ago
    Is it reproduceable? If so, easy: set a conditional breakpoint on the ones where the problem is known to occur. Step through them. A database migration is a pretty serialized operation. It’s perfect. Having lots of data or lots of iterations is really no burden unless you think debugging means manually stepping through everything.
    - eurasiantiger 4y ago
      Let’s say it’s spurious and seemingly resource-dependent; data shape issues etc. would be apparent from the result data and maybe not need that much debugging. Speaking from experience, a migration is also a pretty buffered operation (especially over a network), and stopping the migration at a breakpoint before the failure occurs will almost certainly give all layers enough time to flush this and that so that the problem magically disappears.
- janci 4y ago
  The opposite is also true: debugger changes timings drastically, it removes race conditions, code suddenly works when you run it in debugger, and stops working without.
- lawn 4y ago
  > but developers are extremely underqualified, I get it. And the most annoying thing about them is that they don't realize it, and thinks they know it all and calls everyone who doesn't work like they do noobs.
hardware2win 4y ago
Unless you write in some crazy, rapidly changing env. Then you learn debugger like once? twice? thrice? And still they are not this complex >but one has to balance the time spent learning & managing fancier tools versus the time spent getting the job done. There is funny saying which goes like this You can save 2h of reading debugger docs with 12 years of using prints
- toast0 4y ago
  Maybe I'm weird, but when I'm debugging, the problem could be in my code, library code, runtime code, or kernel code. Usually the first two can use the runtime debugger, but the runtime code needs a different debugger (usually gbd/lldb), and the kernel needs a third debugger (if you even get one). And sometimes I care about the frontend, so there'a a web debugger and maybe a windows debugger for the browser. Thankfully, I've never needed to debug the windows kernel, that would be a whole nother level. Sometimes I'm working on projects with multiple languages, so then I need to debug in Erlang, Perl, PHP, Javascript, hopefully not much Python, userland C, kernel level C. My degree from the printf school of debugging works on all of those. But still, sometimes, printf isn't enough, and you've got to spend the half day figuring out how to get the debugger to work in your current environment, and then the situation often just pops right out (but sometimes it doesn't and you're still just wondering... but now in a much more powerful and dangerous tool). Personally, tcpdump is my favorite debug hammer, but printf is second. FreeBSD's kernel debugger is pretty neat (especially over an IPMI serial console), but fills me with dread when I need it.
carlmr 4y ago
>Perhaps you have to find a spare IO pin attached to an LED Maybe just a spare IO pin and an oscilloscope.
deleted 4y ago
[deleted]
fatcookies 4y ago
Sometimes even poking a spare IO pin is insufficient! I once encountered a hardware issue where a single instruction was being executed twice and this was only revealed by routing the least significant bits of the program counter onto IOs. Only after counting the number of cycles that the offending instruction took revealed the issue.
rsaxvc 4y ago
>Perhaps you have to find a spare IO pin attached to an LED I made a write-only UART on an ST7. Clocking worked out to 500kbit because that was the first configuration I found where I could make the mark and space bits take an equals number of cycles. I still remember thinking: why in the world is the timing for each of these instructions so different?
natly 4y ago
I would be glad even having printf when debugging glsl shaders.
- mbrodersen 4y ago
  I found that using the final pixel color as your “printf” works wonders. You can turn any proposition into a color and directly see the debug pixel values on screen. A simple example is displaying your normals as RGB.
garyrichardson 4y ago
I haven't coded for a while, but here's a weird situation where print() worked better in some cases for me -- you know how people say "I have better learning retention when I take notes by hand"? I found that sometimes the act of writing the print() statement helped to focus my mind and think about what I was trying to debug. For example, what specific aspects of the data structure do I need to see and why? How do I want to frame the relationship between two or more variables? Stuff like that would sometimes lead to the discovery of the bug before I even completed the print() line. Seeing the state is faster with a debugger is probably faster, but the process is an analog to explaining the situation to a rubber duck.

rurban 4y ago

boardwaalk 4y ago
That's a high horse you've got there. There is a vast class of bugs that are not memory bugs and many languages where memory bugs are just not an issue.
- hgomersall 4y ago
  Not only that, but the bugs I find most difficult to deal with (like races) I find have a tendency to disappear in a debugger. Tracing output is what's needed here, and that's just a slightly more structured print.
- userbinator 4y ago
  I have debugged plenty of memory bugs without using a debugger. Debugging multithreaded/async code is an entirely deeper level of hell, and there's been plenty of times where just having a debugger attached was enough to make the code work, or building unoptimised/with debugging information. On the other hand, carefully placed prints can catch the culprit without affecting the timing so much that the bug disappears.
Cerium 4y ago
I have hunted plenty of bugs that only show up when the debugger is not connected to the target.
eurasiantiger 4y ago
I’d like to see you debug a database migration with a runtime debugger. The issue starts after about two million entries and only affects a subset of them. Have fun!
- hamburglar 4y ago
  Is it reproduceable? If so, easy: set a conditional breakpoint on the ones where the problem is known to occur. Step through them. A database migration is a pretty serialized operation. It’s perfect. Having lots of data or lots of iterations is really no burden unless you think debugging means manually stepping through everything.
  - eurasiantiger 4y ago
    Let’s say it’s spurious and seemingly resource-dependent; data shape issues etc. would be apparent from the result data and maybe not need that much debugging. Speaking from experience, a migration is also a pretty buffered operation (especially over a network), and stopping the migration at a breakpoint before the failure occurs will almost certainly give all layers enough time to flush this and that so that the problem magically disappears.
janci 4y ago
The opposite is also true: debugger changes timings drastically, it removes race conditions, code suddenly works when you run it in debugger, and stops working without.
lawn 4y ago
> but developers are extremely underqualified, I get it. And the most annoying thing about them is that they don't realize it, and thinks they know it all and calls everyone who doesn't work like they do noobs.

hardware2win 4y ago

Unless you write in some crazy, rapidly changing env. Then you learn debugger like once? twice? thrice? And still they are not this complex >but one has to balance the time spent learning & managing fancier tools versus the time spent getting the job done. There is funny saying which goes like this You can save 2h of reading debugger docs with 12 years of using prints

toast0 4y ago
Maybe I'm weird, but when I'm debugging, the problem could be in my code, library code, runtime code, or kernel code. Usually the first two can use the runtime debugger, but the runtime code needs a different debugger (usually gbd/lldb), and the kernel needs a third debugger (if you even get one). And sometimes I care about the frontend, so there'a a web debugger and maybe a windows debugger for the browser. Thankfully, I've never needed to debug the windows kernel, that would be a whole nother level. Sometimes I'm working on projects with multiple languages, so then I need to debug in Erlang, Perl, PHP, Javascript, hopefully not much Python, userland C, kernel level C. My degree from the printf school of debugging works on all of those. But still, sometimes, printf isn't enough, and you've got to spend the half day figuring out how to get the debugger to work in your current environment, and then the situation often just pops right out (but sometimes it doesn't and you're still just wondering... but now in a much more powerful and dangerous tool). Personally, tcpdump is my favorite debug hammer, but printf is second. FreeBSD's kernel debugger is pretty neat (especially over an IPMI serial console), but fills me with dread when I need it.

carlmr 4y ago

>Perhaps you have to find a spare IO pin attached to an LED Maybe just a spare IO pin and an oscilloscope.

deleted 4y ago

[deleted]

fatcookies 4y ago

Sometimes even poking a spare IO pin is insufficient! I once encountered a hardware issue where a single instruction was being executed twice and this was only revealed by routing the least significant bits of the program counter onto IOs. Only after counting the number of cycles that the offending instruction took revealed the issue.

rsaxvc 4y ago

>Perhaps you have to find a spare IO pin attached to an LED I made a write-only UART on an ST7. Clocking worked out to 500kbit because that was the first configuration I found where I could make the mark and space bits take an equals number of cycles. I still remember thinking: why in the world is the timing for each of these instructions so different?

natly 4y ago

I would be glad even having printf when debugging glsl shaders.

mbrodersen 4y ago
I found that using the final pixel color as your “printf” works wonders. You can turn any proposition into a color and directly see the debug pixel values on screen. A simple example is displaying your normals as RGB.

garyrichardson 4y ago

I haven't coded for a while, but here's a weird situation where print() worked better in some cases for me -- you know how people say "I have better learning retention when I take notes by hand"? I found that sometimes the act of writing the print() statement helped to focus my mind and think about what I was trying to debug. For example, what specific aspects of the data structure do I need to see and why? How do I want to frame the relationship between two or more variables? Stuff like that would sometimes lead to the discovery of the bug before I even completed the print() line. Seeing the state is faster with a debugger is probably faster, but the process is an analog to explaining the situation to a rubber duck.