[LCP]segmentation fault core dump

[Erik Mouw]

On Mon, Feb 04, 2002 at 11:18:01AM -0500, Mike & Penny Novack wrote:
> 
> > 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).

I am from the time when interactive debuggers were available, and I
thought they were great (I loved Borland's Turbo Debugger on DOS). But
then came the day I created a huge multi processing application (over
30 processes running on 1 to 10 machines). At that point I learned that
because of the lock, wait, and timeout behaviour of the applications
interactive debuggers simply broke down. The only way to debug was to
let the processes dump core and run the core files through an old
fashioned debugger (gdb program core ; bt ; quit).

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

When writing userland code, I always put "displays" in every function I
write. Why? Because when I write a function, I know exactly what input
is considered valid. When I look two weeks later I can't remember the
exact details, so I also don't know *why* the program fails. For
example:

	/* write string "str" at position "pos" */
	int write_string(char *str, int pos)
	{
		assert(str != NULL);
		assert((pos >= 0) && (pos < 80));

		/* ... */
	}	

If that triggers an assertion, I know that one of the calling functions
passed the wrong arguments and the gdb backtrace shows me exactly which
function that was.

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

Agreed. Thinking about the program is *crucial* for debugging. A
non-interactive ("old fashioned") debugger forces you to think about
your program simply because a debug/edit/compile/run session takes so
much time that a little bit of thinking already helps you speeding up
that process quite considerably. Non-interactive and batch debugging
look tedious and slow at first, but once you understand how to work
with it, it makes a debug session a lot faster. It happened more than
once that I found a bug in a co-worker's program within five minutes
simply because I understood how to use a non-interactive debugger while
his only debug technique was mindless stepping for hours on end in an
interactive debugger.

You will also learn that non-interactive and batch debuggers change the
way you program and will actually help you create programs with less
bugs. Having spend some time with non-interactive and batch debuggers
also improves your interactive debugging techniques.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A.K.Mouw at its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/