Date: Thu, 18 Jan 2001 15:09:06 +0100 From: Xavier Galleri <xgalleri@enition.com> To: freebsd-hackers@FreeBSD.ORG Cc: Alfred Perlstein <bright@wintelcom.net> Subject: Information on kernel crash dump analysis Message-ID: <3A66F902.7010108@enition.com> References: <20010111163903.E6FF737B400@hub.freebsd.org> <3A5DE59F.6060602@enition.com> <3A5E090B.40601@enition.com> <20010111114318.C7240@fw.wintelcom.net> <3A632009.1030604@enition.com> <20010115083842.V7240@fw.wintelcom.net> <3A632DD3.1040202@enition.com> <20010115090944.W7240@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi everybody, I have made some progress on my kernel crash dump issue and here is a little contribution for those who would encounter the same problem as the one I got to deal with kernel stack dump. To begin, I recall the actual issue which is : how could I get the stack dump of the current process when a crash occurs inside an interrupt handler ? The clue lies in the use of the 'curpcb' information (current process control block, or alike). Traditionally, this is where at least part of the current process-specific kernel information are stored (such as kernel stack base adress, user values of CPU register set, ...). The problem I encountered is that, in the context of an interrupt handler, both DDB (during on-line crash debugging) and GDB (during post-mortem crash dump analysis) give me for 'curpcb' the one at the time of crash, which is (surely) that of the kernel (I deduced this from that 'curproc' is 0). Anyway, this is not the one I need, and I still wonder how this could be get with no special trick ! Thus, since my problem is rather deterministic, I decided to 'printf' the 'curpcb' (and 'curproc') short before the panic condition occurs. And then I could apply the following manual technic to get the stack dump (let's say your 'curcpb' value is 0xCURPCB). (kgdb) p /x ((struct pcb*)0XCURPCB)->pcb_ebp $0 = 0xCUREBP (kgdb) p /x ((struct pcb*)0XCURPCB)->pcb_eip $1 = 0xCUREIP (kgdb) frame 0xCUREBP 0xCUREIP #0 ... /* This normally tells you where you were at the time the next function has been called */ ... (kgdb) info frame 0xCUREBP 0xCUREIP Stack frame at 0xCUREBP: eip = 0XCUREIP in 'function' (path/source.c:line); saved eip 0xPREVEIP called by frame at 0XPREVEBP ... Then, you apply the 'frame' command using 0xPREVEBP and 0XPREVEIP and this way recursively as long as you need (or can ;-). To sum up, the 'frame' command is used to display one frame level execution state and the 'info frame' is used to know from where the frame has been created so that we could get the previous 'frame' data ! Hope this helps, Xavier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A66F902.7010108>