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

121–130 of 208 posts

Re: What a good debugger can do

#121

Post by RMPR »

turtledragonfly wrote: post #95

I use GDB almost daily, and used Visual Studio pretty deeply for many years (and still a little bit, nowadays), but I must say I am still a "printf debugging" aficionado (or better: real logging). I like many of the features that debuggers can provide, and I think this is a good article to set aspirational goals for what is possible. But my lived experience has generally been that it's a buggy, fuzzy, moving target i…

20+ years is... a lot. I do agree with the sentiment though. At first I was printf debugging because didn't know better. Then discovered debuggers and my mind was blown. But when I reached the point where I hit bugs that would magically disappear when running the program through a debugger, I finally understood that there's value in becoming good at both debugging styles.

Re: What a good debugger can do

#122

Post by macjohnmcc »

turtledragonfly wrote: post #95

I use GDB almost daily, and used Visual Studio pretty deeply for many years (and still a little bit, nowadays), but I must say I am still a "printf debugging" aficionado (or better: real logging). I like many of the features that debuggers can provide, and I think this is a good article to set aspirational goals for what is possible. But my lived experience has generally been that it's a buggy, fuzzy, moving target i…

I have been programming professionally since 1986 and still nothing beats logging or having chunks of specialized code to do dumps of some data to files so you can analyze them with tools better suited for the purpose. Ideally though you don't want to have to modify the code to diagnose the problem especially if it's a crash caught in the wild and you have a chance to live debug it. I would love more useful visualization tools in the debuggers (mostly VS for me) that would be very helpful in all situations like debugging crash dumps.

Re: What a good debugger can do

#123

Post by sebastianconcpt »

aidenn0 wrote: post #68
igouy wrote: post #53

Earlier quoted context omitted.

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

Yeah. That's the normal way to work for a Smalltalk debugger.

I remember once debugging a thread without killing it. I've asked a customer to click on a link that would get to a bug while having remotely opened the IDE that was serving that user session, setting a conditional halt. Seen it halting, fixing the bug and saving the method with the halt removed and let the thread run. All the user saw was a long request that ended in service instead of that bug.

Re: What a good debugger can do

#124

Post by macjohnmcc »

RMPR wrote: post #121
turtledragonfly wrote: post #95

I use GDB almost daily, and used Visual Studio pretty deeply for many years (and still a little bit, nowadays), but I must say I am still a "printf debugging" aficionado (or better: real logging). I like many of the features that debuggers can provide, and I think this is a good article to set aspirational goals for what is possible. But my lived experience has generally been that it's a buggy, fuzzy, moving target i…

20+ years is... a lot. I do agree with the sentiment though. At first I was printf debugging because didn't know better. Then discovered debuggers and my mind was blown. But when I reached the point where I hit bugs that would magically disappear when running the program through a debugger, I finally understood that there's value in becoming good at both debugging styles.

Debugging issues with multithreaded code can be difficult because you could be looking at race condition that only happens when the code is running at full speed and debugging pausing one or all threads could give you an different experience than the real world.

Re: What a good debugger can do

#125

Post by indymike »

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…

I usually wait for someone to accidentally try to merge a bunch of conditional logic wrapping logging, prints or stdio.write type stuff and take that as the opportunity to introduce them to the debug tab in the editor... and give a quick tutorial on conditional breakpoints and how to go up and down the call stack.

It's amazing how many developers go sometimes a decade before they learn to use a debugger.

Re: What a good debugger can do

#126

Post by hobs »

alexdig wrote: post #98
hobs wrote: post #59

Earlier quoted context omitted.

Pycharm/Intellij stuff does everything you mention in a fairly simple GUI that doesn't make you understand how to set conditional variables, but encourages you to realize you want to

do you know if it's possible to step back in pycharm/intellij? the article mentions some debuggers having this ability, but i never saw an option in pycharm. learning how to undo my last step would save so much time. right now, i have to anticipate a risky step and run that line in the debugger console.

Unfortunately I dont think there's any time traveling debugger - you can pretty easily go up and down the stack to see where the caller did x and write something in the console to do y, or you can set conditionals that would always trip when you are about to do something risky, but not go back in time.

Re: What a good debugger can do

#127

Post by carapace »

nuancebydefault wrote: post #43
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.

> never proceed without [total] confidence in your understanding

The fellow I learned that from was apenwarr, FWIW.

Re: What a good debugger can do

#128

Post by aidenn0 »

leni536 wrote: post #106
aidenn0 wrote: post #68

Earlier quoted context omitted.

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

> Ideally all debug features (breakpoints, watchpoints, tracepoints &c.) will work running both forwards and backwards. Executing arbitrary code in the program's context is also a regular debug feature, but I don't think many reversible debuggers allow this.

Hence "ideally"

Re: What a good debugger can do

#129

Post by bornfreddy »

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…

To offer an opposite view, I haven't used (or missed) a debugger for decades, in a whole range of programming languages and environments. It was only recently when I had to disentangle some legacy spaghetti code that I have set it up - and once refactoring is done, I'll probably shell it again.

The reason I don't usually use (/need) a debugger is that I know how the code should behave, because I thought about it in advance. Or, if it is not mine, I expect it to be readable and maintainable, otherwise I push for cleanup instead. If it is written in small manageable chunks, covered with tests and if it has good logging (which is necessary anyway - there will probably be no debugger available in production), I simply don't see the added value of a debugger. If it is not, it is not a debugger that is missing. :-)

That said, it is still a valuable learning tool because it helps understand the flow of the code, and it helps when refactoring spaghetti code. Reverse engineering also comes to mind... But other than that I can't be bothered to set it up either.

Re: What a good debugger can do

#130

Post by akkartik »

jcranmer wrote: post #112
akkartik wrote: post #56

Earlier quoted context omitted.

The big problem with debuggers in my experience is the difficulty of setup. They take a lot of code to build, and if you use a slightly different language or compiler or OS you're SoL. Or at least facing some rabbitholes of unknown depth. The most sophisticated debuggers seem to target C or Lisp. But lately I don't use either. I've never gotten time-travel debugging in gdb to work. And it's been out for more than 10…

> I've been watching https://rr-project.org for a while. The instructions still say, "build from source". rr should be in most distros at this point. (It's been in Debian since at least 2014).

Thanks so much! I just tried it out and finally got to see time travel debugging working with my own eyes[1]. I'm glad to have it in my toolbox.

[1] Though I had to use sudo a few times, reboot, see some scary warning that it might not work reliably, read https://github.com/rr-debugger/rr/wiki/Will-rr-work-on-my-sy... and https://github.com/rr-debugger/rr/wiki/Zen.

Post reply on HN