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

41–50 of 208 posts

Re: What a good debugger can do

#41

Post by fluoridation »

ska wrote: post #38
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.

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 printf-debugging instead."

Re: What a good debugger can do

#42

Post by fluoridation »

ghosty141 wrote: post #18
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

Visual Studio supports conditional and printing breakpoints for both C and C++. I tend to use them rarely because they really hurt performance, though. I only use them if I need to be able to turn them on and off at will, which hardcoded __debugbreak()s don't allow, obviously.

Re: What a good debugger can do

#43

Post by nuancebydefault »

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…

'Design simple and robust systems...' and 'never proceed without confidence in your understanding...'. When I was a freshman, I would have said that. Then I entered the professional world. Complex problems are solved using complex solutions. Complete understanding is non-existing. Robustness is a relative term.

Re: What a good debugger can do

#44

Post by aidenn0 »

akkartik wrote: post #36
aidenn0 wrote: post #28

Earlier quoted context omitted.

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?

Mentioned in TFA is "rr"; it serves up to gdb the history of the program and you can use tracepoints (also mentioned in TFA) to essentially retroactively add prints. Gdb is ... not particularly ergonomic, but it is eminently scriptable and writing programs to generate arbitrary logs post-facto is a useful skill.

Undo is another one for Linux programs, and I think I've seen developers from them post here.

Re: What a good debugger can do

#45

Post by [deleted] »

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…

[deleted]

Re: What a good debugger can do

#46

Post by cmontella »

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…

It can work but it depends on the system. One field in which it's very useful is game development. I'm working on a language that has time travel debugging as a feature, so you can rewind a game back to a previous state. I've found it useful when there's a momentary bug that would be hard to recreate. With time traveling, you pause, rewind, inspect state, fix the bug in situ, then resume from that point to check that the behavior is correct.

Here's an example: http://docs.mech-lang.org/#/examples/bouncing-balls.mec

If you want these kinds of features in other systems, they'll have to be architected to support them. For example, the external database will have to be rewound as well. If it doesn't support that feature, then cool language-level debugging features won't be as useful.

Re: What a good debugger can do

#47

Post by Jorengarenar »

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

Re: What a good debugger can do

#48

Post by zwieback »

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.

Re: What a good debugger can do

#49

Post by werat »

jcranmer wrote: post #25
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…

> How do they work? Painfully. If you're on Linux, you get to use a mixture of poorly-documented (e.g., ptrace) and undocumented (e.g., r_debug) features to figure out the state of the program. Combine this with the debugging symbols provided by the compiler (DWARF), which is actually a complicated state machine to try to encode sufficient details of the source language, and careful reading of the specification makes…

> Debuggers need to do more things

It's true that coming up with an interface for an abstract debugger is harder, but it's not impossible. Microsoft created Debug Adapter Protocol (https://microsoft.github.io/debug-adapter-protocol/), which is conceptually similar to LSP. It's not perfect, but covers most basic operations pretty well, while leaving to the debugger to deal with the implementation details.

Re: What a good debugger can do

#50

Post by HdS84 »

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…

Most of it can be done by the c# debugger, especially in the laid versions of visual studio.
Post reply on HN