41–50 of 164 posts
Delete your debug cruft!
Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…
Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…
I have also seen the print statements added for debugging alter the timing with the same effect on more than one occasion, appearing to “fix” the issue.
If anyone is making you feel ashamed for using one of the most fundamental, bread and butter debugging techniques, that's a red flag about that person. Not you. If there are better tools available, fine, use 'em. But there is absolutely nothing wrong with tossing out a console log to see what's going on.
The problem with all these 'print debugging is good' and 'print debugging articles are bad' is that none of them provide any context. Print debugging is just one tool in a box full of tools. Pick the right one for the right job. An article that walks through how to make that decision would be very useful. An article that just picks a side in a decades-old debate is just noise.
I do think that it’s worth learning your debugger well for programming environments that you use frequently.
In particular, I think that the debugger is exceptionally important vs print debugging for C++. Part of this is the kinds of C++ programs that exist (large, legacy programs). Part of this is that it is annoying to e.g. print a std::vector, but the debugger will pretty-print it for you.
I wrote up a list of tips on how to use gdb effectively on C++ projects awhile back, that got some discussion here: https://news.ycombinator.com/item?id=41074703
It is tricky. I understand why people have a bad experience with gdb. But there are ways to make it better.
What print debugging and debuggers have in common, in contrast to other tools, is that they can extract data specific to your program (e.g values of variables and data structures) that your program was not instrumented to export. It's really a shame that we generally don't have this capability for production software running at scale.
That's why I'm working on Side-Eye [1], a debugger that does work in production. With Side-Eye, you can do something analogous to print debugging, but without changing code or restarting anything. It uses a combination of debug information and dynamic instrumentation.
I've used both print and proper debuggers plenty. I tend to lean on print debugging more these days. The thing about debuggers, in addition to often being a headache to set up, it usually seems tricky and time-consuming to get it to step to the lines you actually want to examine and skip the stuff you don't. And if you step past something but then later realize it was important, time to start over. It's often faster…
Agree, there are some time travel debuggers though but either only for some programming languages or expensive commercial or only for linux e.g. rr-debugger[0]. Also there is rerun [1] that is only for image processing pipeline debugging. I wish there was something similar like rerun but for code: you record the whole program running and capture all snapshots then stop it running. Now you can analyze all app executio…
Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…
To be fair though: printing also will likely impact timing and can change concurrent behaviour as well. Still agree that print debugging is more useful in such situations (and I prefer it in general).
Stepping through with a debugger will take you at least a minute per cycle, won't turn up the concurrency issue, and will spend a great deal of your daily concentration budget.
Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe. To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that a…
Just like printing, a debugger would be a suboptimal tool to use for that usecase.