Date: Tue, 18 May 1999 12:37:26 +0930 From: Greg Lehey <grog@lemis.com> To: Dennis <dennis@etinc.com> Cc: Ruslan Ermilov <ru@ucb.crimea.ua>, questions@FreeBSD.ORG Subject: Re: assembly listing from crash Message-ID: <19990518123726.P89091@freebie.lemis.com> In-Reply-To: <199905171526.LAA12169@etinc.com>; from Dennis on Mon, May 17, 1999 at 10:20:52AM -0400 References: <199905171301.JAA11626@etinc.com> <199905171301.JAA11626@etinc.com> <19990517170835.C3078@relay.ucb.crimea.ua> <199905171526.LAA12169@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <tsleep+27>: movl 0xb8(%ebx),%eax
> 0xc013ee2d <tsleep+33>: andl $0x20000040,%eax
> 0xc013ee32 <tsleep+38>: cmpl $0x40,%eax
> 0xc013ee35 <tsleep+41>: jne 0xc013ee49 <tsleep+61>
> 0xc013ee37 <tsleep+43>: pushl $0x0
> 0xc013ee39 <tsleep+45>: pushl $0x1
> 0xc013ee3b <tsleep+47>: pushl 0xbc(%ebx)
> 0xc013ee41 <tsleep+53>: call 0xc0138440 <ktrcsw>
> 0xc013ee46 <tsleep+58>: addl $0xc,%esp
> 0xc013ee49 <tsleep+61>: call 0xc0205a0c <splhigh>
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990518123726.P89091>