What a good debugger can do
werat.dev
What a good debugger can do
1–10 of 208 posts
Re: What a good debugger can do
#2This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often.
Re: What a good debugger can do
#3Seems 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 in history, and even record the entire program execution and visualize control flow and data flow history.
TL;DR: That's fantastic! But if you need any of it you're already "doing it wrong".
Context: I've recently been using a compiler for a C-like language that targets a simple 64-bit VM, the point being there's no debugger for the stack (the VM is written in Rust; I could put a debugger on that and just deal with the extra level of abstraction using e.g. features like those described above.)
So how do you cope?
Design simple and robust systems that can be understood in action easily via printf/log. Use tried-and-true off-the-shelf components (including algorithms and datastructures.) Write in small increments, compile often, never proceed without complete confidence in your understanding of the system. When the inevitable bugs appear, and they can't be discovered through just thought or a rereading of the code, then you bisect: often literally (LoC) but also conceptually. Solve the puzzle and eliminate the places where puzzles can hide in the first place.
I quite literally see how a having a debugger would lead to worse code. (Even if you don't use it.) This isn't news btw:
> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
-- Brian Kernighan, 1974
(The feeling is different: like instead of a wild adventure, programming this way feels like gardening in an orderly and well-kept garden.)
Re: What a good debugger can do
#4This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often. [1] https://lkml.org/lkml/2000/9/6/65
I really enjoyed this thought in that mail: “Tough. There are two kinds of reactions to that [time lost from a bug you introduced in kernel dev]: you start being careful, or you start whining about
a kernel debugger.”
Re: What a good debugger can do
#5This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often. [1] https://lkml.org/lkml/2000/9/6/65
Contrasting perspective from John Carmack [1] who drops into a debugger all the time to explore state, understand program behavior, debug things, etc.
Looks like there is no universal golden path. Differing environments make different approaches effective.
Re: What a good debugger can do
#6Seems 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…
In the real world, programmers are brought into projects with literally millions of lines of code that have been developed over years or decades by tens or hundreds of programmers. They are under intense time pressure to fix bugs that they likely didn’t create. This is normal and debuggers are invaluable. No offence, but what you’re describing is a lovely ideal that only exists if you work mostly alone or on small things.
Re: What a good debugger can do
#7A whole world of creative opportunities open up when the toolchain and related debugging tools don't suck. Check out this wild video[1] of someone modifying and debugging a game in real time.
Re: What a good debugger can do
#8I 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 the job.
Re: What a good debugger can do
#9Seems 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…
That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies.
I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreover, I had to come with my own 3D visualization tool, once I got fed up with pen and paper for converting 3D coordinates to actual meshes, or using Blender for that. For me, a debugger (and debugging tools in general) is irreplaceable. I'm not saying my field is the most complex one, because it clearly isn't - but in that field, I can't think of any other way I could do what I do.
Re: What a good debugger can do
#10This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often. [1] https://lkml.org/lkml/2000/9/6/65
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-travelling debuggers is really a game changer, just having the ability to travel back in time to figure out who set the value that causes the code to crash. Hot reload is also a wonderful thing (unfortunately, the fragmentation of tooling in Linux makes getting this working properly very difficult).