From owner-freebsd-questions Mon May 17 20: 8: 1 1999 Delivered-To: freebsd-questions@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id C187615107 for ; Mon, 17 May 1999 20:07:33 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA29350; Tue, 18 May 1999 12:37:28 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA01526; Tue, 18 May 1999 12:37:26 +0930 (CST) Date: Tue, 18 May 1999 12:37:26 +0930 From: Greg Lehey To: Dennis Cc: Ruslan Ermilov , questions@FreeBSD.ORG Subject: Re: assembly listing from crash Message-ID: <19990518123726.P89091@freebie.lemis.com> References: <199905171301.JAA11626@etinc.com> <199905171301.JAA11626@etinc.com> <19990517170835.C3078@relay.ucb.crimea.ua> <199905171526.LAA12169@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199905171526.LAA12169@etinc.com>; from Dennis on Mon, May 17, 1999 at 10:20:52AM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 17 May 1999 at 10:20:52 -0400, Dennis wrote: > At 05:08 PM 5/17/99 +0300, Ruslan Ermilov wrote: >> [forwarded to -questions] >> On Mon, May 17, 1999 at 09:04:09PM -0400, Dennis wrote: >>> >>> What is required to get an assembly listing of the crashpoint when >>> analyzing a crash dump? >> >> Read the documentation about ``gdb''. >> man 1 gdb >> info gdb > > Gee thanks. I've already done that, but it doesnt talk much about crashes. Yes, I thought that was less than helpful, too. First, start gdb with the -k flag. Here's an example from a recent crash I wrote up. They were written to somebody who knows his way around crash dumps, so the comments are less verbose than you might like. I've added some where they appear necessary. > $ gdb -k kernel.debug vmcore.32 > #0 boot (howto=260) at ../../kern/kern_shutdown.c:285 > #1 0xc013d0e1 in panic (fmt=0xc0225893 "page fault") > at ../../kern/kern_shutdown.c:446 > #2 0xc01fea5a in trap_fatal (frame=0xc022b674, eva=184) > at ../../i386/i386/trap.c:942 > #3 0xc01fe713 in trap_pfault (frame=0xc022b674, usermode=0, eva=184) > at ../../i386/i386/trap.c:835 > #4 0xc01fe362 in trap (frame={tf_es = 16, tf_ds = -1073348592, tf_edi = 0, > tf_esi = -957523464, tf_ebp = -1071466812, tf_isp = -1071466852, > tf_ebx = 0, tf_edx = 20, tf_ecx = -896400832, tf_eax = -957523464, > tf_trapno = 12, tf_err = 0, tf_eip = -1072435673, tf_cs = 8, > tf_eflags = 66118, tf_esp = -957523464, tf_ss = -1035257088}) > at ../../i386/i386/trap.c:437 > #5 0xc013ee27 in tsleep (ident=0xc6ed59f8, priority=20, > wmesg=0xc02172d1 "getblk", timo=0) at ../../kern/kern_synch.c:388 > > Look at this frame's code: We're looking at this one because it's the frame where the trap occurred. The frames above are part of the panic procedure. > (kgdb) f 5 > #5 0xc013ee27 in tsleep (ident=0xc6ed59f8, priority=20, > wmesg=0xc02172d1 "getblk", timo=0) at ../../kern/kern_synch.c:388 > 388 int s, sig, catch = priority & PCATCH; > (kgdb) x/10i 0xc013ee27 > 0xc013ee27 : movl 0xb8(%ebx),%eax > 0xc013ee2d : andl $0x20000040,%eax > 0xc013ee32 : cmpl $0x40,%eax > 0xc013ee35 : jne 0xc013ee49 > 0xc013ee37 : pushl $0x0 > 0xc013ee39 : pushl $0x1 > 0xc013ee3b : pushl 0xbc(%ebx) > 0xc013ee41 : call 0xc0138440 > 0xc013ee46 : addl $0xc,%esp > 0xc013ee49 : call 0xc0205a0c > > Looks innocuous enough. The instruction at 0xc013ee27 loads the eax register with the word at address 0xb8 from the value in the ebx register. .. > (kgdb) i reg Look at the registers to see what's in ebx. > eax 0x0 0 > ecx 0x0 0 > edx 0x0 0 > ebx 0xc00e0400 -1072823296 > esp 0xc022b5d0 0xc022b5d0 > ebp 0xc022b6c4 0xc022b6c4 > esi 0xc6ed59f8 -957523464 > edi 0x0 0 > eip 0xc01f56e8 0xc01f56e8 > eflags 0x0 0 > cs 0x0 0 > ss 0x0 0 > ds 0x0 0 > es cannot read u area ptr for proc at 0 > > This is the load address of the movl instruction: The address is 0xb8 + 0xc00e0400. > (kgdb) x/10x 0xc00e04b8 > 0xc00e04b8: 0x00040000 0x00000000 0x00000000 0x00000000 > 0xc00e04c8: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc00e04d8: 0x00000000 0x00000000 > > In other words, it's in core. So why a page fault? > > The essence: we got a page fault on an instruction which shouldn't > have page faulted. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message