[gumby]

The end of the essay implies that "debugger" is a poor name because of course you still have to fix the bug yourself. If we call it instead "bug-location-explorer" I find them invaluable for certain problems. In particular when you have a very complex system that takes a while to get into its fragile state, when I/O is difficult (e.g. many embedded systems), or as others have noted here when you are spelunking others' code. Breakpoints are crucial since most bugs with modern languages are wrong output and not bus errors.

I started out as a user of "print" as a debugging technique, but early on Bill Gosper took pity on me and introduced me to ITS DDT and the Lispm debugger. They both had an important property that they were always running, so when your program fails you can immediately inspect the state of open files and network connections. No automatic core dumps except for daemons. The fact that you explicitly have to attach a debugger before starting the program is a regression in Unix IMHO.

It doesn't surprise me that Linus doesn't use one as kernel debugging is its own can of worms.

[greenyoda]

> If we call it instead "bug-location-explorer"...

Or even more generally, a "run-time code explorer", since debuggers are useful for understanding code even if you're not trying to fix a bug.

[toast0]

I don't know if it's always been the case, but it is certainly possible to attach and detach a debugger from an existing process, gdb/lldb takes -p for pid. (Although, detaching from threaded processes seems to have a risk of the process ending up stuck in my experience)

Briefly popping into the debugger can be a really quick way to find where an infinite loop is happening, especially if it's not in your code, or not where you expect. I found this especially helpful in diagnosing a FreeBSD kernel loop I ran into, once the location of the loop was clear, the fix was simple.

[Gibbon1]

As you can see we have identified the crash in this process. Good have Steiner attach GBD to it to find out what is wrong. Mein Fuhrer... Steiner... Steiner accidentally killed the process and rebooted the server.

[Gibbon1]

> The fact that you explicitly have to attach a debugger before starting the program is a regression in Unix IMHO.

Not sure if this is exactly true for Unix. For embedded targets you can often attach to a running uP with GDB.

[aaronbrethorst]

How about 'state inspector?' This is, of course, exactly what this article proposes doing with "print" statements, but print is a paltry state inspection tool compared to them, ahem, debuggers to which we are accustomed.