Subject: Re: kern/20914: kernel panic in sysctl_procargs()
To: Andrew Brown <atatat@atatdot.net>
From: David Laight <david@l8s.co.uk>
List: netbsd-bugs
Date: 04/08/2003 17:45:45
>
> and since name is a variable local to sys___sysctl() (whose address is
> apparently 0xcfcd8f10), i should be able to find the sys___sysctl()
> stack frame somewhere around 0xcfcd8f10. let's see...pointer,
> pointer, int, a couple of size_ts, another pointer, an array of ints
> called name (CTL_MAXNAME aka 12 in length), and another
> pointer...that's 19 x 4 (this is i386), so we look at this:
>
> (gdb) x/48x 0xcfcd8f00
> 0xcfcd8f00: 0xc030cae0 0x00040000 0xcfcc8500 0x00040000
> 0xcfcd8f10: 0x00000001 0x00000030 0x00000277 0x00000001
> 0xcfcd8f20: 0x0000002e 0x00000000 0xcfcd8f68 0xc0b9b000
> 0xcfcd8f30: 0x0180d00a 0x2f83d00a 0x00000000 0x00000004
> 0xcfcd8f40: 0xcfcd8fa0 0xc03a1e3b 0xcfae3688 0xcfcd8f80
> 0xcfcd8f50: 0xcfcd8f78 0xc0ac6340 0xbdbbd2e0 0xbfbfedbc
> 0xcfcd8f60: 0x00000004 0x00000000 0x00000006 0xc043f464
> 0xcfcd8f70: 0xcfcd8fa0 0xc0699fb0 0x00000000 0x00000000
> 0xcfcd8f80: 0xbfbfedbc 0x00000004 0x0807b000 0xbfbfedb8
> 0xcfcd8f90: 0x00000000 0x00000000 0xc0ac8500 0xc0ac8500
> 0xcfcd8fa0: 0xbfbfed5c 0xc0100c6b 0x0000001f 0x0000001f
> 0xcfcd8fb0: 0x0000001f 0x0000001f 0x00000004 0xbfbfedbc
>
> now...the { 0x1, 0x30, 0x277, 0x1 } is the name array (where the
> initial 0x1 is presumably CTL_KERN). going back to the ddb stackdump
> that says the fourth argument to sysctl_procargs() was 0xcfcd8f0c,
> that must be the address of sizep (known here as oldlen), the 0x40000
> value. since i've dumped the vmspaces of all the processes from the
> kernel core, i can say that the ps process was 334 which has a paddr
> (according to ps) of cfcc8500. that value appears at 0xcfcd8f08 in
> the dump above. so...where's the thing that i feed to gdb to step to
> that stack frame?
Ok - how to follow the stack by hand...
Each stack frame (on i386) looks like:
locals
saved ebp
return address
arguments
The ebp values point to each other, so once you've found one frame, you
can sort out the traceback.
The 'trap' frame will be different, I don't know the layout for netbsd.
But the trap itself will push 'flags', cs, eip (ie eip on top of stack).
Now I can't see the ebp chain in the above fragment - but I don't have
the hex return addresses of the known frame to help.
If you dump out a lot more of the stack (above and below) the part shown,
you should be ably to identify the frames for the sysctl sequence
and the part the gdb finds. The gap in the middle will contain the
registers at the time of the fault!
David
--
David Laight: david@l8s.co.uk