What a good debugger can do • Hacker News Board

Re: What a good debugger can do

#101

Post by pjmlp » Fri, Mar 10, 2023, 7:34 PM UTC

RcouF1uZ4gsC wrote: post #52

I have mostly found the people who dismissed debuggers tended to be more Unix/Linux people, probably because raw gdb is such a huge pain to use. Windows developers and Visual Studio developers where the debugging experience is so easy, tend to sing the praises of debuggers. I wonder if it a bit of sour grape for the Unix/Linux crowd?

Depends on the UNIX, Solaris, HP-UX and NeXT/macOS are all UNIXes with good debugging experience.

Naturally none of them have had raw gdb, rather modern graphical debuggers.

Re: What a good debugger can do

#102

Post by donadigo » Fri, Mar 10, 2023, 7:37 PM UTC

The article provides a pretty good overview of the landscape of debuggers out there. I find myself using printf debugging whenever something is a dynamically evolving state and I need to monitor just the relevant bits of it and breakpoints when something is either crashing or requiring a deeper thought about how the code executes.

That said, I still think there's quite a bit of improvement to be made, which is why I started building a new debugger for myself which puts a lot more focus on breakpoint-less workflow, speed of iteration and scripting ability: (demo) https://www.youtube.com/watch?v=qJYoqfTfuQk It's geared mainly for gamedev, but I also do use it many times to e.g debug itself.

Re: What a good debugger can do

#103

Post by AtNightWeCode » Fri, Mar 10, 2023, 7:38 PM UTC

People who learn the tools are much more productive. Two features I often miss is that I sometimes want to copy whole data structures as JSON. There are workarounds for it in some langs. Then there is this annoying thing that some things are optimized away even in debug mode. So you have to add in variables just for debugging which is of course an anti-pattern.

Re: What a good debugger can do

#104

Post by leni536 » Fri, Mar 10, 2023, 7:39 PM UTC

> Breakpoints, oh my breakpoints

This is a good list, but one thing missing: catchpoints. Particularly useful with time travel debugging. catch throw + reverse-continue immediately tells you who threw an exception, and you can continue debugging from there.

Re: What a good debugger can do

#105

Post by intelVISA » Fri, Mar 10, 2023, 7:40 PM UTC

avg_dev wrote: post #71

Thanks very much for posting this article. I found it very intriguing. I read it carefully but I didn’t visit all the links or watch all of the in-line videos. I would say that for the most part I am a printf-style debugger. I remember reading some years ago (on HN, I believe) about time travel debugging in - I believe - C# and I was really impressed but I don’t code in C# so it soon left my mind. I have a deep appre…

Not tried it unfortunately but there's a travel-time debugger for C(++) somewhere.

Re: What a good debugger can do

#106

Post by leni536 » Fri, Mar 10, 2023, 7:44 PM UTC

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…

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

Re: What a good debugger can do

#107

Post by Quekid5 » Fri, Mar 10, 2023, 7:46 PM UTC

donadigo wrote: post #102

The article provides a pretty good overview of the landscape of debuggers out there. I find myself using printf debugging whenever something is a dynamically evolving state and I need to monitor just the relevant bits of it and breakpoints when something is either crashing or requiring a deeper thought about how the code executes. That said, I still think there's quite a bit of improvement to be made, which is why I…

That's an excellent observation which I think agrees with my own.

If you already have a good idea of the control flow (and thus, expected behavior), but there's some minute detail that goes wrong, you just need a few strategically placed prints to see the state evolution. If the problem is control flow related, you might first need to get a grasp of that before going into the weeds.

Re: What a good debugger can do

#108

Post by quelsolaar » Fri, Mar 10, 2023, 7:48 PM UTC

To me the debugger is perhaps the most important tool and I much rather have a bad editor with a good debugger than a great editor without. I find that typing code is never the limiting factor in productivity, being able to understand what your code does is, and a good debugger is a game changer. The same goes for languages, there is a lot of discussion about what various languages do, but not what debuggers are available for them. Visual studio has many faults, but IMO it runs circles around the competition when it comes to te debugger.

Re: What a good debugger can do

#109

Post by henrydark » Fri, Mar 10, 2023, 7:48 PM UTC

One of my favorite "debuggers" is OllyDbg.

I will never forget the first time I changed a few lines of assembly of a running game (starsiege tribes, around 2005), and then I saw friend-or-foe indicators through walls.

That kind of "hot reloading" was special.

Re: What a good debugger can do

#110

Post by jcranmer » Fri, Mar 10, 2023, 7:49 PM UTC

deckard1 wrote: post #94

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…

> Time-travelling debuggers is really a game changer Core dumps have existed forever. They give you a stack trace and register values at the time of crash. Even better, you don't need a debugger running at the time of crash and you can dig into dumps sent from nontechnical users. Sure, Bret Victor's demo was cool. But time travel debugging is so completely oversold at this point that I can't take anyone seriously tha…

I've debugged core dumps before. It's not been a particularly pleasant experience--good luck trying to do something like `call V->dump()` (dump out an easy-to-understand representation of a complex value to stdout... oh that doesn't exist anymore, can't use that functionality!)

The most useful aspect of time-travel debugging for me, personally, has been when the test case that causes a crash is refusing to be reduced, and the function that crashes does so on like the 453rd time it's called. Jumping straight to the crash, then reverse-continuing to a break point cuts out so much time of debugging (especially because it saves you if you accidentally continue the breakpoint one too many times; otherwise, you'd have to start the entire, tedious process from the beginning).