Using GNU's GDB Debugger
dirac.org
dirac.org
"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.
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.
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.)
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.
At least for gdb, there are some great graphical front-ends like kdbg and (the slightly odd but definitely functional) ddd.
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
if (condition) { printf(interesting state); }
Purify stops leaks. Quantify allows adding a few hacks to give 20x speedup, sometimes 100x with practise.
Windows only AFAIK.
Of course they perform a different function to gdb in general.
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.