Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Dec 2006 16:08:22 +0200 (EET)
From:      Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: ddb(4) spoils kernel stack in CURRENT?
Message-ID:  <20061220151813.R91910@atlantis.atlantis.dp.ua>
In-Reply-To: <20061220124032.GC23698@deviant.kiev.zoral.com.ua>
References:  <20061219175917.L84683@atlantis.atlantis.dp.ua> <20061220130559.P54963@atlantis.atlantis.dp.ua> <20061220124032.GC23698@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

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@atlantis.dp.ua
nic-hdl: LYNX-RIPE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061220151813.R91910>