

Using GNU's GDB Debugger - parenthesis
http://dirac.org/linux/gdb/

======
dcminter
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 that I came around to.

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

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

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

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

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

    
    
      if (condition) { printf(interesting state); }
    

in the code than conditional breakpoints.

------
zandorg
I use Rational Purify, which shows all memory leaks, and Rational Quantify,
which gives statistics.

Purify stops leaks. Quantify allows adding a few hacks to give 20x speedup,
sometimes 100x with practise.

Windows only AFAIK.

~~~
kingmaker
Valgrind is also incredibly useful if you are working with Linux.

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

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

