Re:The unreasonable effectiveness of print debugging
by ruslan on Saturday April 24, 2021 @10:22PM
(#26929849)
You don't put printf() in critical sections, instead you collect some statistics. Once critical section is over you can freely print collected data for further analyzis. Or you can print it once a second. This simple technique works well for debugging racing conditions, performance issues (profiling), memory leaks, kernel drivers and bare-metal stuff where timing is a concern. So, yes "Print debugging always works...", but must be used wisely. :-)
Re:The unreasonable effectiveness of print debugging
by Shikadi on Sunday April 25, 2021 @01:58AM
(#26930605)
Collecting statistics can change race conditions too, it's just less likely
Re:The unreasonable effectiveness of print debugging
by bluGill on Saturday April 24, 2021 @09:45PM
(#26929666)
Debuggers don't work in the situation you described either.
Nope, print debugging does not always work. Please stop saying that. Sure, it's often useful and often works. But go try to debug a race condition, or bug in some locking mechanism with print statements. I'll wait as you add a bunch of print statements, and then learn the harsh lesson that you are now debugging a completely different program with very different performance characteristics that now doesn't deadlock where it used to deadlock because you slowed down one of the threads massively as it spends time it used to not spend logging stuff.
"Step debuggers, on the other hand, are essentially “no-code” debuggers — extremely useful for the purpose for which they are designed, still useful for adjacent purposes, and a great place to start if you know the tool well, but ultimately not as powerful if your needs exceed their capacities."
I guess you'd think this if you thought print debugging "always works". But I promise you it is equally (if not easier) to exceed the capabilities of print statements in some scenarios.