ddb(4) spoils kernel stack in CURRENT?
Dmitry Pryanishnikov
dmitry at atlantis.dp.ua
Wed Dec 20 06:08:33 PST 2006
Hello!
On Wed, 20 Dec 2006, Kostik Belousov wrote:
>>> So it looks like a regression in CURRENT vs RELENG_6 (either ddb 'spoils'
>>> the stack somehow, or kgdb fails to unwind it).
>
> Could you further localize the problem, i.e. try to backtrace CURRENT dump
> by RELENG_6 kgdb and vice versa.
1. Trying to analyze CURRENT's kernel dump under RELENG_6 fails miserably.
Here are the relevant pieces of 'diff -u' ('-' = output of kgdb run from
CURRENT, '+' = the same kernel image and coredump, but kgdb run from
RELENG_6):
This GDB was configured as "i386-marcel-freebsd".
+kgdb: kvm_read: invalid address (0x0)
-#0 doadump () at pcpu.h:166
-166 pcpu.h: No such file or directory.
- in pcpu.h
+#0 0x00000000 in ?? ()
(kgdb) bt
-#0 doadump () at pcpu.h:166
-#1 0xc04aad4c in boot (howto=260)
- at /mnt3/usr/CURRENT/src/sys/kern/kern_shutdown.c:411
-#2 0xc04aaff7 in panic (fmt=0xc05ffbbf "from debugger")
- at /mnt3/usr/CURRENT/src/sys/kern/kern_shutdown.c:567
-#3 0xc044238e in db_panic (addr=-1068723113, have_addr=0, count=-1,
- modif=0xe4b4795c "") at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:433
-#4 0xc0442327 in db_command (last_cmdp=0xc0660a04, cmd_table=0x0)
- at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:401
-#5 0xc04423e2 in db_command_loop ()
- at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:453
-#6 0xc044402d in db_trap (type=3, code=0)
- at /mnt3/usr/CURRENT/src/sys/ddb/db_main.c:222
-#7 0xc04c96d1 in kdb_trap (type=3, code=0, tf=0x0)
- at /mnt3/usr/CURRENT/src/sys/kern/subr_kdb.c:502
-#8 0xc05ddfc1 in trap (frame=0xe4b47aec)
- at /mnt3/usr/CURRENT/src/sys/i386/i386/trap.c:621
-#9 0xc05ca84b in calltrap ()
- at /mnt3/usr/CURRENT/src/sys/i386/i386/exception.s:139
-#10 0x00000000 in ?? ()
-Previous frame inner to this frame (corrupt stack?)
+#0 0x00000000 in ?? ()
2. Alas, trying to analyze RELENG_6's kernel dump under the CURRENT gives
the same behaviour: kgdb issues 'kgdb: kvm_read: invalid address (0x0)'
and shows just '#0 0x00000000 in ?? ()' instead of backtrace.
So, cross kernel dump analysis between RELENG_6 and CURRENT seems to be
impossible now ;(
Sincerely, Dmitry
--
Atlantis ISP, System Administrator
e-mail: dmitry at atlantis.dp.ua
nic-hdl: LYNX-RIPE
More information about the freebsd-current
mailing list