What a good debugger can do
61–70 of 208 posts
Re: What a good debugger can do
#62I 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
#63Earlier 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…
Re: What a good debugger can do
#64This is what a good debugger can do: https://twitter.com/yiningkarlli/status/1628612150041382912 (Tomorrow Corporation)
Re: What a good debugger can do
#65Re: 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.
Example from this thread: https://news.ycombinator.com/item?id=35098434
Re: What a good debugger can do
#67I'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.
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
#68Earlier 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...
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
#69Re: What a good debugger can do
#70a 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 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.