Earlier quoted context omitted.
One trick to minimize debugging footprint is to store logs in a ring buffer/array list and defer printing. It's not perfect, but if you use a ring buffer, you can avoid making any syscalls until you are truly ready to print. Thread synchronization can obviously still be a problem, but that can be mitigated by using thread local buffers or by using a lockless ring buffer. Ring buffers are also nice because you can als…
This is genius. I hadn’t heard of this logging style before. I’m going to try it tomorrow morning.
Debug Programs by Modifying Them
31–37 of 37 posts
Re: Debug Programs by Modifying Them
#32If I inherit code or libraries from someone else, I use the debugger without shame.
For my own code, using the debugger is a sign something is wrong. This demonstrates a need for extra logging: How can I troubleshoot software in production in the field if I can't do it on my own machine.
Print style debugging is usually reserved for interfaces between my and someone else's code, to clarify the contract.
None of this is a religion of course.
Re: Debug Programs by Modifying Them
#33Earlier quoted context omitted.
Stepping through can be a pain sometimes, because to find certain bugs it's easier to look through a log throughout a longer run of the program, and see how the state changes. Of course, a debugger that could generate a log like that instead of pausing execution would give you that benefit too.
Yes, this seems like an odd missing feature that would give me the best of both worlds: a "watchpoint", but that outputs to a log. It may be possible in VS debug or gdb but it's not really .. surfaced?
Re: Debug Programs by Modifying Them
#34Earlier quoted context omitted.
Stepping through can be a pain sometimes, because to find certain bugs it's easier to look through a log throughout a longer run of the program, and see how the state changes. Of course, a debugger that could generate a log like that instead of pausing execution would give you that benefit too.
Yes, this seems like an odd missing feature that would give me the best of both worlds: a "watchpoint", but that outputs to a log. It may be possible in VS debug or gdb but it's not really .. surfaced?
Re: Debug Programs by Modifying Them
#35Honestly, I don't get this debate. If you were to take the pain points of debug by print, and address them, you'd come up with a debugger. Being able to put those "print" statements anywhere without recompiling, being able to go step-by-step in the code, etc. And sure, that's not always available. Both end up having impacts on the thing they observe. A print() call can cause microscopic delays that are enough to caus…
> Both end up having impacts on the thing they observe. A print() call can cause microscopic delays that are enough to cause a race condition not to trigger, as can waiting on a breakpoint, etc. I seldom encounter a program that is sensitive to a print() but robust to a debugger. Prints perturb programs _less_ than debuggers do. > If you were to take the pain points of debug by print, and address them, you'd come up…
Re: Debug Programs by Modifying Them
#36Earlier quoted context omitted.
You had colors? Back in the day, all I had was an unused GPIO pin and an oscope. One pulse, assert code 1, two pulses, assert code 2, etc. (I’m kind of riffing on an old Dilbert cartoon, but debugging with a scope was common in my life in embedded systems.)
Are you sure it's a Dilbert cartoon and not an XKCD? https://xkcd.com/378/
Here's the Dilbert I was thinking of:
Re: Debug Programs by Modifying Them
#37Print debugging is okay, if you don't remove the print statements when you are finished. This technique is called logging or tracing, and is nothing new. It makes total sense to insert a lot of logging statements into your code, which can be switched on when you need to diagnose something. This can be also used then in production, where you can't just change code (but switch the log level in the config). Very useful…