Date: Mon, 19 Apr 2004 11:45:37 +0200 From: Jorn Argelo <jorn@wcborstel.nl> To: Greg 'groggy' Lehey <grog@FreeBSD.org> Cc: questions@freebsd.org Subject: Re: Kernel debugging question Message-ID: <200404191145.37313.jorn@wcborstel.nl> In-Reply-To: <20040418224837.GP74025@wantadilla.lemis.com> References: <200404182001.46732.jorn@wcborstel.nl> <20040418224837.GP74025@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey Greg,
I forgot to add the following kernel option:
makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbol
I did enable the rest though. This is the output of the debugging, though it
seems somewhat different then the output on the FreeBSD page. Do you think
the folks at current or hackers can do something with this? Or am I
forgetting something?
Thanks,
Jorn
[root@smeagol] ~# gdb -k /boot/kernel/kernel.debug /home/jorn/dump/vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xcdcb7bef
stack pointer = 0x10:0xcdcb7bec
frame pointer = 0x10:0xcdcb7c04
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 11 (idle)
trap number = 12
panic: page fault
syncing disks, buffers remaining... 2107 2107 2107 2107 2107 2107 2107 2107
2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107
giving up on 1594 buffers
Uptime: 4h26m37s
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
warning: cannot find file for module nvidia.ko
Error while mapping shared library sections:
nvidia.ko: No such file or directory.
Error while reading shared library symbols:
nvidia.ko: No such file or directory.
Reading symbols
from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols
for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols
from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols
for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols
from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug...done.
Loaded symbols
for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug
Reading symbols
from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug...done.
Loaded symbols
for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug
Reading symbols
from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug...done.
Loaded symbols
for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
(kgdb)
On Monday 19 April 2004 00:48, you wrote:
> On Sunday, 18 April 2004 at 20:01:46 +0200, Jorn Argelo wrote:
> > Hey folks,
> >
> > I've been trying to debug my kernel. I've successfully extracted a kernel
> > dump as described in the development handbook. However, as soon as I come
> > across this step, I don't know how to continue:
> >
> > # cd /usr/obj/usr/src/sys/KERNCONF
> > # gdb -k /boot/kernel/kernel.debug /var/crash/vmcore.0
> >
> > The problem is, kernel.debug doesn't exist at all.
>
> This means you didn't build one.
>
> > I did an locate.updatedb as root and try to find it then, but I
> > still couldn't find it. Hopefully somebody can point me into the
> > right direction
>
> First you need to build a debug kernel. This probably means that the
> dump you have is "the one that got away". You could do some limited
> analysis of the stripped kernel, but that's Deep Magic.
>
> > (I used
> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern
> >eldebug.html)
>
> You might take a look at
> http://www.lemis.com/papers/Taiwan/tutorial.pdf, which is a little
> more update. Note, though, that it's still a draft. If you see any
> mistakes, please contact me.
>
> Greg
> --
> When replying to this message, please copy the original recipients.
> If you don't, I may ignore the reply or reply to the original recipients.
> For more information, see http://www.lemis.com/questions.html
> Note: I discard all HTML mail unseen.
> Finger grog@FreeBSD.org for PGP public key.
> See complete headers for address and phone numbers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404191145.37313.jorn>