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

111–120 of 208 posts

Re: What a good debugger can do

#111

Post by jcranmer »

werat wrote: post #49
jcranmer wrote: post #25

Earlier quoted context omitted.

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

If I'm coming up with a new language, let's call it Drustzig, I can implement the LSP and get support for IDEs (and possibly xref tools and the like) essentially for free. Now to get debugging support for my language... I have to traipse around through every major debugger and beg them to merge Drustzig patches to make it work.

The protocol you've linked (or the similar gdbserver protocol) essentially implements an IDE debugger mapping. Well, most of one: everything is basically being passed as strings, so if you want smart stuff, you kind of have to build in the smart stuff yourself. It doesn't help the other parts of the process; if you want to build a new gdb, you have to do all the parsing of debug info for C, C++, Drustzig, etc. yourself... and you have to integrate the compiler expression stuff yourself. If you want to build a better time-traveling debugger, or a better crash debug format, or something similar, well, the gdb remote protocol lets gdb talk to your tool so all you have to implement is essentially low-level program state (e.g., enumerate registers of a thread, read/write arbitrary memory locations, etc.). But this isn't covered by the thing you've listed either, and it still relies on the debugger supporting a particular protocol.

Re: What a good debugger can do

#112

Post by jcranmer »

akkartik wrote: post #56
aidenn0 wrote: post #44

Earlier quoted context omitted.

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.

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

Re: What a good debugger can do

#113

Post by whatever1 »

quelsolaar wrote: post #108

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

Debugging is the one reason I tolerate interpreted languages.

The fact that you can pause execution and start writing commands to execute on the fly in the debug console is VERY POWERFUL.

Re: What a good debugger can do

#114

Post by pcdevils »

mark_undoio wrote: post #72
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…

For time travel debugging in Go: The Delve debugger for Go supports debugging rr traces: https://github.com/go-delve/delve/blob/master/Documentation/... Undo (who I work for) maintain a fork that debugs our LiveRecorder recordings: https://docs.undo.io/GoDelve.html Either rr ( https://rr-project.org/ ) or our UDB debugger ( https://undo.io/solutions/products/udb/ ) can do some time travel debugging of Go programs via…

The same tools don't work on windows either. Delve works well as a remote debugger against go on windows server though. Another fun one is go won't create dumps on panic on windows when GOTRACEBACK=crash is set.

Re: What a good debugger can do

#115

Post by MikeSchurman »

armchairhacker wrote: post #60

This is what a good debugger can do: https://twitter.com/yiningkarlli/status/1628612150041382912 (Tomorrow Corporation)

This was on hacker news a few days ago but there wasn't much interest, which is surprising.

Setting a data breakpoint, then rewinding time, then fixing the error in code (while game is running), hot-reloading code and continuing the run with it fixed. All from a recording of a panic dump from another user.

This is next level stuff. Extremely impressive.

Re: What a good debugger can do

#116

Post by lispm »

whatever1 wrote: post #113
quelsolaar wrote: post #108

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

Debugging is the one reason I tolerate interpreted languages. The fact that you can pause execution and start writing commands to execute on the fly in the debug console is VERY POWERFUL.

...and you don't need even 'interpreted languages' for that...

Re: What a good debugger can do

#117

Post by quelsolaar »

whatever1 wrote: post #113
quelsolaar wrote: post #108

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

Debugging is the one reason I tolerate interpreted languages. The fact that you can pause execution and start writing commands to execute on the fly in the debug console is VERY POWERFUL.

As a C developer, I REALY want a interpreted C compiler with a crazy good debugger for this reason. On average I think C has really good debuggers (its a simple language that has been around for a long time) but there is so much more one could do. A few years ago i wrote a prototype called OPA, with some cool potential features. https://www.youtube.com/watch?v=pvkn9Xz-xks

Re: What a good debugger can do

#118

Post by justeleblanc »

maleldil wrote: post #66
Jorengarenar wrote: post #47

>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

Do we know if that person is a freshman student who barely started coding?

Re: What a good debugger can do

#119

Post by justeleblanc »

aflag wrote: post #84
Jorengarenar wrote: post #47

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

Linus Torvalds famously dislike them: https://lwn.net/2000/0914/a/lt-debugger.php3

At least he did 23 years ago. Have debuggers evolved in the past 23 years?

Re: What a good debugger can do

#120

Post by ska »

fluoridation wrote: post #41
ska wrote: 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…

The world isn't printf debugging or debugger only.

Some things are really amenable to the debugger, especially simple bugs. Really especially ones that should have been caught by static analysis anyway but that's a separate issue.

The issue is that firing up a debugger can easily become a fishing expedition. If you don't understand the system behavior and you don't know where the real problem is, you can end up manually stepping through many many layers of a system trying to see what it's doing. Add asynchonicity and this can take hours before you get to the 20 lines of logic that is the actual problem.

Ideally you have better logging and introspection, so the problem is caught in a way that leads you to those 20 lines immediately.

And of course design can make a huge difference in how understandable and localizable things are.

The problem a lot of inexperienced developers run into is if they are used to having a featureful debugger available it can become the only tool they have in their toolbox, and they are rewarded by how quickly it helps them fix the kind of mistakes their inexperience leads them to making a lot of. When they run into a real issue, they can be hitting "step" for hours....

The other pernicious side of this particular coin is that it can lead to localized understanding of the problem and make it really easy to apply a localized solution. With inexperienced people this can quickly lead to band-aid solutions all over the place. With any luck someone more experienced is looking it over and pointing out they should go after the actual problems, but left unchecked it can make a real mess.

Post reply on HN