[LCP]segmentation fault core dump
Mike & Penny Novack
stepbystepfarm at shaysnet.com
Tue Feb 5 04:51:52 UTC 2002
> Developing a mindset that says "it's not doing what I want, what have
I told
> it to do instead" is crucial in developing your debugging skills. Both
Mike
> and I come from an age before interactive debuggers were available. We
had
> basically two tools, inserting tracing code and post-mortem core dumps
> printed on reams of paper.
>
Just want to add something to what Andrew said. He is correct, I do come
from before interactive debuggers were available, but that's not
precisely why I outlined the thought process without a debugger. Once
you know how to debug, an interactive debugger can save lots of time,
especially if there are many bugs (with debuggers that let you reset
values, you can do that and proceed to the next bug).
But that's the key point, once you know how to debug. They do not
provide the thought process, so even using an interactive debugger you
have to have some idea what you want to look at. In other words, you
have to already be able to visualize, "if I knew what the value of THAT
variable at THAT point I'd know which of two problems existed". Using
the debugger, you just stop at that point and look at the value
contained by the variable. Using the old fashioned method, you stuck in
a "display" and recompiled. But you still had to know what to look at.
Looking
at EVERYTHING is useful only if the number of variables is small.
Stepping through code is useful only if there aren't millions of lines
executed between the points of interest. "Batch debuggers" are more
useful tools then. And they can examine complex relationships between
variables (things you couldn't easily see "just looking") and do the
equivalent of a "floating assertion" (ie: if this computational
condition ever becomes true, break the execution at the previous line).
But you are unlikely to be successful using a "batch debugger" without a
great deal more "old fashioned" experience than using an "interactive
debugger" (ie: you wouldn't have a clue what "rules" to set).
Mike
More information about the linuxCprogramming
mailing list