Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 May 1997 07:13:06 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        hackers@FreeBSD.ORG, jhay@zibbi.mikom.csir.co.za
Subject:   Re: help needed with kernel debuging and gdb
Message-ID:  <199705042113.HAA26318@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>I'm getting a kernel panic with my latest ipx changes (the struct proc *
>thingies). It panic trying to execute at address 0. I can't get gdb to
>show me which function is doing that. The backtrace don't want to go
>past trap(). I have tried setting the frame like in the example in
>the handbook, but it does not seem to work. Is there someone that can
>tell me how?

If address 0 is called, then there should be a trap immediately and the
return address should by at the base of the stack.  Print the value at
$esp and disassemble from there (p/x *(int *)$esp ...).  [gdb seems to
be challenged by expressions in `disass' commands.  ddb handles this
better (x/ia *$esp).]

If address 0 is jumped to, then the function that jumped won't be
directly available.  The frame will contain the return address for this
function and disassembling and/or [pseudo-]executing the code just before
this address will show the function that jumped provided indirect call
addresses haven't changed.

>======
>Fatal trap 12: page fault while in kernel mode
>fault virtual address   = 0x0
>fault code              = supervisor read, page not present
>instruction pointer     = 0x8:0x0
>stack pointer           = 0x10:0xf34a2ec4
>frame pointer           = 0x10:0xf34a2f18
>code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, def32 1, gran 1
>processor eflags        = interrupt enabled, resume, IOPL = 0
>current process         = 156 (IPXrouted)
>interrupt mask          = 
>trap number             = 12
>panic: page fault
>=====

BTW, it's annoying that this long message gets printed before traps
to ddb.  It occurs internally for disassembly at $eip, including for
`sh r' and scrolls the output of `sh r' off the screen, and there is no
scrollback or general more-style paging in ddb.  `sh r' also uses too much
vertical space and would be unusable if there were a few more registers.
Even i386's have more than 25 registers counting the special ones.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705042113.HAA26318>