Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What a good debugger can do

werat.dev

Post reply on HN
Print view View original

11–20 of 208 posts

Re: What a good debugger can do

#11

Post by akkartik »

AndriyKunitsyn wrote: post #9
carapace wrote: post #3

Seems as good a hook as any to hang this rant... > a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point…

That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreove…

But it sounds like you had to come up with your own tools because a debugger wasn't enough?

That's my biggest criticism of debuggers having used both approaches: you forget that sometimes you need new tools. Whereas with prints you're constantly building new instrumentation for yourself.

https://merveilles.town/@akkartik/106138280776488247

Re: What a good debugger can do

#12

Post by sebastianconcpt » 

    a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, can pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point in history, and can even record the entire program execution and visualize control flow and data flow history.    
    I should mention that the perfect debugger doesn’t exist.
People pretends Smalltalk doesn't exist?

Re: What a good debugger can do

#13

Post by CyberDildonics »

akkartik wrote: post #11
AndriyKunitsyn wrote: post #9

Earlier quoted context omitted.

That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreove…

But it sounds like you had to come up with your own tools because a debugger wasn't enough? That's my biggest criticism of debuggers having used both approaches: you forget that sometimes you need new tools. Whereas with prints you're constantly building new instrumentation for yourself. https://merveilles.town/@akkartik/106138280776488247

Whereas with prints you're constantly building new instrumentation for yourself.

What does this mean? Formatting text differently is still text, which the parent post was just explaining doesn't cut it.

Re: What a good debugger can do

#14

Post by Decabytes »

I've always been curious about Debuggers. How do they work? How do they connect to a program and step through it. Why can't more compiled languages integrate debuggers inside of them so that you can debug the program without using a separate tool?

And why can't we create interfaces to debuggers so that other text editors can integrate with them, much like how we do we LSPs?

*EDIT*

Thanks for all the responses! I've now heard from multiple sources that debugging on Linux is unpleasant, and it seems like the whole process is challenging regardless of the platform.

Re: What a good debugger can do

#15

Post by Lichtso »

One style that haven't seen discussed is a hybrid / mixture of in-code (e.g. printf trace-logs) and out-of-code (using external tools like an attached debugger) debugging.

What I do is I encode conditional breakpoints in the source code, (compile and) run the program with a debugger attached. The nice thing is you can have complex conditions using all kinds of functions from your surrounding code and you can have them permanently, even check them into the VCS. It is kind of like placing asserts which don't panic but trap into the debugger and they can be globally enabled / disabled.

Re: What a good debugger can do

#16

Post by yellowjobby »

> We can snapshot the program whenever something non-deterministic happens (syscall, I/O, etc) and then we just reconstruct the program state at any moment by rewinding it to the nearest snapshot and executing the code from there. This is basically what UDB, WinDBG and rr do.

QEMU does this too. This plus its GDB stub means one can time-travel-debug pretty much anything on any emulated architecture.

https://www.qemu.org/docs/master/system/replay.html

Re: What a good debugger can do

#17

Post by akkartik »

CyberDildonics wrote: post #13
akkartik wrote: post #11

Earlier quoted context omitted.

But it sounds like you had to come up with your own tools because a debugger wasn't enough? That's my biggest criticism of debuggers having used both approaches: you forget that sometimes you need new tools. Whereas with prints you're constantly building new instrumentation for yourself. https://merveilles.town/@akkartik/106138280776488247

Whereas with prints you're constantly building new instrumentation for yourself. What does this mean? Formatting text differently is still text, which the parent post was just explaining doesn't cut it.

I'm constantly finding new places in my program to add prints to. This isn't just copy changes. (Though that has also had a huge impact occasionally in understanding something. Imagine emitting 2 variables and then focusing on 1 of them. A pattern can pop out of a screenful of iterations of a loop when things line up just right.)

Re: What a good debugger can do

#18

Post by ghosty141 »

Lichtso wrote: post #15

One style that haven't seen discussed is a hybrid / mixture of in-code (e.g. printf trace-logs) and out-of-code (using external tools like an attached debugger) debugging. What I do is I encode conditional breakpoints in the source code, (compile and) run the program with a debugger attached. The nice thing is you can have complex conditions using all kinds of functions from your surrounding code and you can have the…

Conditional breakpoints are supported for most dynamic languages. With static ones like c++ your way is the only practical way I believe

Re: What a good debugger can do

#19

Post by eschneider »

jcranmer wrote: post #10
choletentent wrote: post #2

This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often. [1] https://lkml.org/lkml/2000/9/6/65

That sort of argument is somewhat defensible in a context like the kernel, where when things go haywire, you can't really expect there to be enough sanity to have a debugger work. But very little code runs in such a context, and it turns out that a well-written debugger has incredible features. Also, Linus is writing this 22 and a half years ago, where the capabilities of debuggers were... far, far less. Time-travell…

Lots of (most?) real-time and embedded code run in a state where suspending/resuming really doesn't work in any useful fashion, so it's logging, and minimal logging at that to figure out what's going wrong in-situ.

That said, much benefit is gained by writing the complicated bits in such a way that they can be tested/debugged/examined independently on a host system.

Re: What a good debugger can do

#20

Post by ghosty141 »

Decabytes wrote: post #14

I've always been curious about Debuggers. How do they work? How do they connect to a program and step through it. Why can't more compiled languages integrate debuggers inside of them so that you can debug the program without using a separate tool? And why can't we create interfaces to debuggers so that other text editors can integrate with them, much like how we do we LSPs? *EDIT* Thanks for all the responses! I've n…

About the latter, there is an LSP equivalent called DAP (debug adapter protocol).
Post reply on HN