Live data from Hacker News

Debug Programs by Modifying Them

merveilles.town

31–37 of 37 posts

Re: Debug Programs by Modifying Them

#31
post #25

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.

There are many variants. One is to put the ringbuffer in a shared memory segment or mmapped file, and use another process to read and print the content.

Re: Debug Programs by Modifying Them

#32
I have different styles of debugging dependent of context.

If 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

#33
post #27

Earlier 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?

This is possible in all JetBrains IDEs, just right-click the breakpoint and configure it that way.

Re: Debug Programs by Modifying Them

#34
post #27

Earlier 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?

In gdb you can put commands to be executed on a breakpoint; you can put necessary prints + continue statement there.

Re: Debug Programs by Modifying Them

#35
post #6

Honestly, 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…

Am I understanding this correctly? Are you saying it's better to change things rather than understanding the existing code?

Re: Debug Programs by Modifying Them

#36
post #12

Earlier 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/

I enjoyed the XKCD. Thanks for that. I'm currently interested in Cynefin and complexity theory in organizations, so it's kind of right up my alley.

Here's the Dilbert I was thinking of:

https://dilbert.com/strip/1992-09-08

Re: Debug Programs by Modifying Them

#37
post #23

Print 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…

honestly, when I approach programming, a primary concern is to spend effort to help make the program easier to modify. I'm not the original proponent of that as a goal, its just something I read somewhere but it really helped me in my career.
Post reply on HN