From owner-freebsd-hackers  Mon Mar  3 22:51:31 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id WAA00668
          for hackers-outgoing; Mon, 3 Mar 1997 22:51:31 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA00663
          for <hackers@FreeBSD.org>; Mon, 3 Mar 1997 22:51:28 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id RAA30428; Tue, 4 Mar 1997 17:49:22 +1100
Date: Tue, 4 Mar 1997 17:49:22 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703040649.RAA30428@godzilla.zeta.org.au>
To: jlemon@americantv.com, msmith@atrad.adelaide.edu.au
Subject: Re: xemacs crashes kernel
Cc: hackers@FreeBSD.org, proff@iq.org
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>> Can you give us the trap message and do the nm /kernel | less thing?

nm /kernel is a poor method.  Use it only when you can't generate a
kernel dump to run gdb on (never for reproducible panics).

>Panic dump (typed by hand):

Urk.  If you have a kernel dump, then you can fish the panic message
out of the message buffer using gdb, e.g.:

	x/1000s msgbufp+12

However, the panic message usually isn't very useful.  The full register
contents, the faulting instruction and a stack trace are more useful.

>	stopped at _fsync+0x73, testb $0x40, 0x18(%eax)

This shows that vp->v_mount is garbage in fsync().  %eax is probably 0.
Unfortunately the panic message doesn't print the full register contents.

>nm /kernel | grep f0137 | sort

This gives less information than the "stopped at" line.

Bruce