Live data from Hacker News

What a good debugger can do

werat.dev

61–70 of 208 posts

Re: What a good debugger can do

#62
post #38

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.

I've found the exact opposite of this starting out. When I started using the debugger a whole lot of things just clicked into place.

Re: What a good debugger can do

#63
post #38

Earlier quoted context omitted.

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.

Weird, I've never run across that. I have wasted a lot of time rebuilding and retesting figuring out where to put a print statement and then figuring out what and how to print it, where a debugger would have let me turn breakpoints on or off and watch different variables in the same run, all without touching the code. I don't think I've ever thought "gee, this debugger sure is getting in my way! I wish I could do pri…

I assume the parent comment is talking about "thinking" (not that I have any personal experience with that).

Re: What a good debugger can do

#65
Just yesterday I was trying to dive into a container running some c program and I took a look at gdb... again, for the n time.. and the whole ordeal of the gdbserver and gdb as a client and the symbol table yadda yadda yadda I just rebuild the program with some printfs displaying data, filename and line number and re ran it. Done. gdb is stifling.

Re: What a good debugger can do

#66

>When people say “debuggers are useless and using logging and unit-tests is much better,” Who? Who does say that? Freshman students who barely started coding? >I suspect many of them think that debuggers can only put breakpoints on certain lines, step-step-step through the code, and check variable values. That alone provides enough value to know debuggers are useful.

> Who? Who does say that? Freshman students who barely started coding?

Example from this thread: https://news.ycombinator.com/item?id=35098434

Re: What a good debugger can do

#67

I'm a debugger lover and Visual Studio's is pretty great but GDB is also awesome. However, when debugging embedded systems with a good trace probe it's another whole world, using on-chip trace capabilities and being able to break on things like register or peripheral access makes it even more exciting. And expensive, unfortunately, since it's such a niche thing.

Just curious how does one build the tools you talked about? I'm referencing both hw and sw: hw part I guess is "on chip trace capabilities" and sw is "break on registers or peripheral access".

I'm not an embedded dev neither am I a debugger developer but I'm playing with toy OS dev so just curious.

Re: What a good debugger can do

#68
post #53
post #29

Earlier quoted context omitted.

Is there a ST implementation with a time-traveling debugger? That's probably the one feature I miss when using sbcl/slime.

Depends what functionality you think "a time-traveling debugger" must provide, Smalltalk implementations usually provide something like this: https://cuis-smalltalk.github.io/TheCuisBook/The-Debugger.ht...

To qualify as "time-travelling" You should at a minimum be able to step and run backwards and inspect the values of variables at a previous point in time.

Ideally all debug features (breakpoints, watchpoints, tracepoints &c.) will work running both forwards and backwards. To meet the standard of the "perfect debugger" from the TFA intro, I would say you should be able to run backwards, modify a function, and run forwards again. I'm not aware of any debuggers that let you do this.

Re: What a good debugger can do

#70
post #31

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…

Have a look at https://rr-project.org/ (features and motivation are on that page). (Also mentioned in the article.)

It works on recorded state. It's not about executing a program again, it's about root causing a failure by going back in time after the failure happened. You can do things like start with a crash, retroactively set a break point and reverse run back in time until you hit it.

It's for real world applications. It was written specifically to debug Firefox, and has since been used for other applications of similar size.

It's basically GDB with extra commands, so very easy to use and learn if you know GDB. Highly recommend.

Post reply on HN