The Practice of Programming (Kernighan and Pike 1999):
"As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places..."
It's a view with which I am familiar. In general, I agree that a programmer must reason about code execution, and that a debugger does not replace this process. However: with all due respect, a symbolic debugger is invaluable while trying to figure why inherited, legacy, spaghetti-ridden code which relies on pearls like parallel arrays in multiple different data structures being in sync crashes at 3 o'clock in the morning.
When I used to hang out in the workstation room at grad school, around midnight, I'd see guys feverishly trying to complete their beginning programming assignments. Invariably, some poor schmo was stuck trying to figure out where they went wrong with a doubly linked list implementation in C. They'd sit transfixed, staring at their code concocting all sorts of wild theories. I'd go up to them and tell them they should really try GDB. They'd always declare that they didn't have the time to learn it. Then at about 3:00 in the morning, they'd be desperate enough to try it. Most of the time, we'd find their bug within a few minutes.
Both debuggers and printf()s have their place. I use both heavily with debugging; DDD's data graph view (http://www.icewalkers.com/scr/n1350/ddd.jpg) is especially invaluable when debugging data structures in C.
Agreed. Stepping through your code in a debugger is SLOW and tedious. Make a change, run the code path again, make a change, run the code path again... boring.
It is much easier to print data in the area you suspect is wrong, then write a small script to get the program to call that code. You make a change and get nearly-instant feedback.
Stepping through in Smalltalk debuggers is (usually) easy and delightful. I had one student in a Smalltalk class (he was a quant, heavy math dude) declare the VisualWorks Smalltalk debugger came from God!
The debugger is so responsive, I routinely have 2 or 3 debugging sessions open, and write code in one of them. I'll write some exploratory code, evaluate it in the current stack context, examine the results, then dismiss it after copying the code back into the original debugger context and modifying it into an actual method. Sometimes, people will put a snippet of code in a comment and say, "debug this!" which is often informative and as easy to do as following a hyperlink. There's never a wait for a compile. It's not perfect -- you can get into trouble trying to debug parts of the system used by the debugger itself -- but for typical application programming, it's a joy! Oh, and with Smalltalk Server Pages, you can debug and step through in a completely natural way the rendering of a web page! (Yes, you'll see that HTML element there, then where you step into the message send for the dynamic HTML generation.)
Add me to the list of people who had previously used a deluge of printf()s.
I've always wanted to be a gdb guru but it just seemed a little mystical and unnecessary. But this tutorial seems like it gets to the point so I'll start reading it tonight. Thanks for the link.
It's one of those programs that I feel I really ought to learn to use (somewhat like emacs) but whenever I try I get that sinking feeling after a while and give up.
At least for gdb, there are some great graphical front-ends like kdbg and (the slightly odd but definitely functional) ddd.
A debugger's a great way to go through a source base of under/badly/not documented code. Ironically enough, GDB's probably the only way to get a good handle of what GCC does internally.
I love gdb's ability to call an arbitrary routine of your code while in a breakpoint. A good print/validation routine for your own data structures is wonderful there.
But yeah, it can turn into a parasitic, addictive time sucker if you don't stay disciplined about it. If all you're wanting is a stack trace here or there, and it doesn't take too long to relink the app, it's usually faster to put an
I've used Valgrind on Linux, but it's one of those applications where I have the time and patience to install it once, but not twice. That's my fault for not taking notes on how I set it up.
It is in some ways as good as Quantify and Purify, except that they're much easier to use, being based around a good GUI.
Um... what? You install valgrind by selecting it from your package manager (e.g. "apt-get install valgrind"). You run it by prepending "valgrind" to the command. Then you read the output. Valgrind is one of the most dummy-proof development tools I'm aware of. For someone to claim that they don't have the patience to "learn" it is just beyond me.
"As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places..."
It's a view that I came around to.