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

31–40 of 208 posts

Re: What a good debugger can do

#31

Post by nijave »

sebastianconcpt wrote: post #12

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

>can step through the code backward and rewind the program state to any point in history

This seems impossible for anything that modifies external state.

Say 1. Open database connection 2. Commit data 3. Close database connection

How would you rewind right before #2 if you've already completed step #3? You'd need the socket/connection you already closed

Unless that means something more like "keep a running record of program state over time"

Re: What a good debugger can do

#32

Post by nuancebydefault »

eschneider wrote: post #19
jcranmer wrote: post #10

Earlier quoted context omitted.

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.

Hmmm I have 20+ years of embedded sw programming experience and can tell you the reason that embedded software is oftentimes not easily debugged using a debugger, is the crappyness of the debugger solution (debug probe, its firmware and its eco system). Also, high end embedded ICs often contain a serious amount if silicon bugs. The fact that it needs to run real-time, is mostly not in the way of the debugging process. In other words, embedded processors and their eco systems tend to be sub-par in terms of developer friendlyness. Addendum SHARC ADSP anomaly list https://www.analog.com/media/en/dsp-documentation/integrated...

Re: What a good debugger can do

#33

Post by akkartik »

aidenn0 wrote: post #27
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

Is your argument "Don't use debuggers because it will prevent you from writing a debugger?"

I'm not arguing "don't use debuggers."

I'm arguing, "don't just use debuggers."

I elaborate more on this argument in the first 2 minutes of this 4-minute video: https://handmade.network/snippet/1561

Re: What a good debugger can do

#34

Post by draegtun »

sebastianconcpt wrote: post #12

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

>> People pretends Smalltalk doesn't exist?

And Factor and many implementations of Lisp too!

Re: What a good debugger can do

#35

Post by shadowofneptune »

sebastianconcpt wrote: post #12

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

Smalltalk images offered introspection, debugging of running processes, etc., but some of the later features listed seem quite impractical to add to the language. "Record the entire program execution," for instance.

That's more or less the point the author makes on the next line: "Different tools support different features and have different limitations." The ideal debugger does not necessarily make for the most ideal programming environment, just as a plane made out of steel is great for structural stability but may not be a good plane.

Re: What a good debugger can do

#36

Post by akkartik »

aidenn0 wrote: post #28
akkartik wrote: post #17

Earlier quoted context omitted.

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.)

There are debuggers that will let you halt your program, go back in time, and then print out each place where a specific variable changes. If that's "interacting with your program through a pane of glass" then shrug .

I'm very happy to hear it! Can you point me at a few of them?

Re: What a good debugger can do

#37

Post by frou_dh »

If someone's preferred language/framework/environment doesn't have a good debugger, or if they simply don't know how to set it up, some percentage of them will start insisting that they don't even want one anyway.

This is the basic Sour Grapes concept.

Re: What a good debugger can do

#38

Post by ska »

WirelessGigabit wrote: post #8

I am a huge proponent of debuggers. Being able to look at state step by step without having to stop, add log statements, recompile and go back are too slow (for me). What concerns me more is that is that I end up working with contractors with 5+ years who don't know how to set up a debugger for the code they are working on. And that concerns me. It's not OR logging OR debugging. It's both. You use the best tool for t…

It's definitely both. Ideally the debugger is never your first resort.

An extremely common failure mode for less experienced developers is messing about in a debugger all afternoon for a problem that should be solvable in 5 minutes. It's a very slow way to learn.

Re: What a good debugger can do

#39

Post by fluoridation »

nijave wrote: post #31
sebastianconcpt wrote: post #12

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

>can step through the code backward and rewind the program state to any point in history This seems impossible for anything that modifies external state. Say 1. Open database connection 2. Commit data 3. Close database connection How would you rewind right before #2 if you've already completed step #3? You'd need the socket/connection you already closed Unless that means something more like "keep a running record of…

Yes, that's what it means. Ideally you'd record the state of memory and CPU after each instruction. In practice you can take snapshots at regular intervals and hook system functions to record their inputs and outputs. If a call has to be replayed the debugger intercepts it and gives the debuggee a recorded result.

Re: What a good debugger can do

#40

Post by aidenn0 »

akkartik wrote: post #33
aidenn0 wrote: post #27

Earlier quoted context omitted.

Is your argument "Don't use debuggers because it will prevent you from writing a debugger?"

I'm not arguing "don't use debuggers." I'm arguing, "don't just use debuggers." I elaborate more on this argument in the first 2 minutes of this 4-minute video: https://handmade.network/snippet/1561

That makes sense. I'm also with you in that programmers forget that their development tools are also programs and they can modify and/or make more of them.
Post reply on HN