Subject: port-i386/9367: i386 kernel crash dump tracebacks not so useful
To: None <gnats-bugs@gnats.netbsd.org>
From: None <cgd@netbsd.org>
List: netbsd-bugs
Date: 02/07/2000 12:21:38
>Number: 9367
>Category: port-i386
>Synopsis: i386 kernel crash dump tracebacks not so useful
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: port-i386-maintainer (NetBSD/i386 Portmaster)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Feb 7 12:20:59 2000
>Last-Modified:
>Originator: Chris Demetriou
>Organization:
>Release: 1.4.x (1.4-branch, as of mid-september 1999)
>Environment:
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
>Description:
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:
(gdb) whe
#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.
>How-To-Repeat:
Get an i386 kernel to crash and dump a core. examine it in gdb.
Note lack of useful information.
>Fix:
Unknown. This is a production system, use of DDB is not an option.
>Audit-Trail:
>Unformatted: