Date: Tue, 15 Aug 1995 07:47:00 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: davidg@root.com, root@kaiwan.kaiwan.com Cc: freebsd-bugs@freefall.FreeBSD.org Subject: Re: kern/688: Page fault: supervisor write, page not present Message-ID: <199508150547.HAA03006@uriah.heep.sax.de> In-Reply-To: <199508150330.UAA19230@freefall.FreeBSD.org> from "David Greenman" at Aug 14, 95 08:30:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As David Greenman wrote: > > >#4 0xf01920b7 in trap () > >#5 0xf018b571 in calltrap () > >#6 0xf0121831 in allocbuf () > ... > > Would you mind additionally doing an 'nm /kernel | sort' and fishing out > the routines around the 0xf018679c? As you may have noticed above, our gdb > screws up the stack decoding at the point of the trap (the panic happend in a > routine that allocbuf() called, not in allocbuf. Someone really needs to fix > that. Alternatively, adding a -g to the kernel Makefile, removing a few .o files (including trap.o), should get you in a state where you are able to say ``frame frame.tf_ebp frame.tf_eip'' from stack frame #4 (in trap()), which will also spot you to the right location. Look into the kernel-debug.FAQ for more explanation (even though the version delivered with 2.0.5 contains bogus references on how to take a core dump -- but you've got one, so don't care). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508150547.HAA03006>