Subject: Autosave of panic backtraces (was Re: Getting into the debugger)
To: Dr. Bill Studenmund <wrstuden@loki.stanford.edu>
From: Brian C. Grayson <bgrayson@marvin.ece.utexas.edu>
List: tech-kern
Date: 01/17/1999 01:00:19
On Fri, Jan 15, 1999 at 01:25:26PM -0800, Dr. Bill Studenmund wrote:
> I'm starting to try to debug the fs locking problems. One of the things
> I'd love to have is a stack trace in a static string (so I can have a
> stack trace both of the code which ran into a lock & panic'd and also the
> code which generated the lock).

  Recently I was wondering, how hard would it be to add code to
panic() to print out a backtrace, and save it somewhere on disk
before dying?  It's probably a bit over my head at this point
as far as implementing it, but I have a few ideas....

  For example, on most i386 boxes, blocks 1-62 are free,
depending on your boot manager and all that.  I'd personally be
willing to set aside all of track 1 for backtrace info.
Or, one can shrink a swap partition by a few blocks, and use
that gap for backtraces.

  If DDB support is not compiled into the kernel, one can merely
print out/log all the return addresses -- I've written a little
40-liner C function that figures them out.  Post-mortem can
translate the addresses at least into function names+offset.

  Then, in /etc/rc.conf "check_panicbacktrace_block=xxx" would tell
/etc/rc at boot time to read in block xxx from the boot disk,
and parse it w.r.t. the appropriate kernel, and save the
backtrace in /var/log/panics or something.

  Opinions?  Should I just go to bed?  :)  (On closer
examination, maybe I would be able to hack this up after all,
at least for my personal use!)

  Happy hacking...

  Brian