From owner-freebsd-hackers Fri Dec 3 6:13:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id DC97A14E9B for ; Fri, 3 Dec 1999 06:13:13 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id JAA88969; Fri, 3 Dec 1999 09:12:47 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14407.53214.998956.352922@trooper.velocet.net> Date: Fri, 3 Dec 1999 09:12:46 -0500 (EST) To: David Scheidt Cc: David Gilbert , freebsd-hackers@freebsd.org Subject: Re: Inverting a gdb -k mapping? In-Reply-To: References: <14407.14812.812358.220983@trooper.velocet.net> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "David" == David Scheidt writes: [...] David> Have you looked a t Greg Lehey's how to debug vinum pages at David> http://www.lemis.com/vinum/how-to-debug.html ? Very much so. The issue is that the whole stack trace (which I have posted in stable before) looks like this: #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xc0152f68 in at_shutdown ( function=0xc0237fc6 <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0x0, queue=12) at ../../kern/kern_shutdown.c:446 #2 0xc0209c15 in trap_fatal (frame=0xc0241260, eva=0) at ../../i386/i386/trap.c:942 #3 0xc02098f3 in trap_pfault (frame=0xc0241260, usermode=0, eva=0) at ../../i386/i386/trap.c:835 #4 0xc0209596 in trap (frame={tf_es = 1835991056, tf_ds = 1701904400, tf_edi = -1073215488, tf_esi = -1058170880, tf_ebp = -1071377704, tf_isp = -1071377784, tf_ebx = -1057735652, tf_edx = 0, tf_ecx = -1057735652, tf_eax = -1073215488, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags = 66054, tf_esp = -1072233935, tf_ss = -1057735652}) at ../../i386/i386/trap.c:437 #5 0x0 in ?? () Now... some very helpful people have pointed out that the value of tf_esp (the stack pointer) does not make sense --- it is not byte aligned. The best guess at analysis currently is that stack corruption is occuring and some function is returning to a NULL value on the stack. Now... this is very hard to debug. I need to find the stack or find information about the stack. It would be really cool to know what function is causing corruption on the stack. But nosing around a large corefile looking for the kernel stack is a long process that tends to make me sleepy. Does the kernel stack start at the same place each boot? Is there a way of finding the stack that caused this call to trap() Help? I'm willing to do quite a lot of grunt work here (it's worth about $4000 to me to solve this problem), but I need some help. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message