Subject: port-i386/9367: i386 kernel crash dump tracebacks not so useful
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 02/07/2000 12:21:38
>Synopsis: i386 kernel crash dump tracebacks not so useful
>Responsible: port-i386-maintainer (NetBSD/i386 Portmaster)
>Arrival-Date: Mon Feb 7 12:20:59 2000
>Originator: Chris Demetriou
>Release: 1.4.x (1.4-branch, as of mid-september 1999)
NetBSD bacon 1.4.1 NetBSD 1.4.1 (GENERIC_CGD) #16: Thu Sep 16 18:52:54 PDT 1999 cgd@bacon:/a/src/src-1-4-branch/sys/arch/i386/compile/GENERIC_CGD i386
NetBSD/i386 kernel crash dump tracebacks in gdb are just about
useless. For instance, consider the following trace provided
by a crash that I just experienced:
#0 0xf023bcce in sys_sysarch ()
#1 0xf023545f in cpu_reboot ()
#2 0xf01876c8 in log ()
#3 0xf023bf5d in trap ()
(the sys_sysarch() thing is just wrong, of course.) The actual
call chain goes way beyond the trap call, though. the kernel
printfs -- the eip reported by the trap handler -- say that this
particular trap() was caused by gdt_compact(). The traceback
should have provided that -- and deeper -- frame information.
Get an i386 kernel to crash and dump a core. examine it in gdb.
Note lack of useful information.
Unknown. This is a production system, use of DDB is not an option.