how to interpret crash?

[Robert Watson]

On Thu, 27 May 2004, David Magda wrote:

> > You don't need the actual kernel.debug to boot with, just the image 
> > around
> > so when you run gdb -k it can pull the symbols out. Otherwise, the
> > installed kernel is stripped.  On -CURRENT, there's a
> > /sys/$arch/compile/$kernelname.debug that you suck in.
> 
> Yes, but I sometimes clean out my compile / object directory and so when
> I need the debugging kernel it's not there (and I may have cvsup'ed my
> source tree). It would be nice if a debugging kernel is sitting there
> beside the kernel that I booted. 

I've you've cvsup'd your source tree, the debugging kernel may not be all
that useful either, as the goal of the debugging symbols is to provide a
mapping from locations in the kernel binary to locations in the kernel
source code.  If you have the same source code and same config file, there
should be little variation in the compiled code and typically building a
fresh kernel from the same pieces is sufficient to provide you everything
you need.  If you've cvsup'd and no longer have the source code for the
old kernel, regardless of having debugging symbols, you're in a much worse
starting point for tracking down the problem.

One important reason that the debugging kernel isn't kept around is space
considerations: in -CURRENT, a 5mb kernel will generally be accompanied by
a 30mb debugging kernel.  Each module with symbols is similarly swollen: 
the agp module is normally 72k, but with debugging symbols is 368k.  It
doesn't take too much of that to fill up most root partitions...

I don't debate your basic point that on a stable system, you're least
likely to find the symbols when you most need them, as the system will run
fine for a long time and then run into some edge case, unusual hardware
failure mode, or whatever, and given that it's been stable for years, you
will find yourself with little debugging recourse.  That's where tricks
like using nm to track down the symbols, turning on dumps by default,
compiling with the necessary DDB bits to generate a stack trace, etc, can
come in quite handy.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research