Subject: Re: kern/20914: kernel panic in sysctl_procargs()
To: David Laight <david@l8s.co.uk>
From: Andrew Brown <atatat@atatdot.net>
List: netbsd-bugs
Date: 04/08/2003 13:48:15
>> (gdb) x/48x 0xcfcd8f00
>> 0xcfcd8f00:     0xc030cae0      0x00040000      0xcfcc8500      0x00040000
>>...
>> 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.

invoking "info registers" right after starting gdb gives me:

...
esp            0xcf6e7abc       0xcf6e7abc
ebp            0xcf6e7e80       0xcf6e7e80
...

0xcf6e7abc is a long way from 0xcfcd8f00.

>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).

mmm...okay.

>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.

um...okay.  i did "x/4000x 0xcfcd8000" and, from looking for pointers
to the stack that appear to point to pointers to the stack, i can
see...

0xcfcd8d30:     0xcfcd8d60
0xcfcd8d7c:     0xcfcd8e30
0xcfcd8dcc:     0xcfcd8e30

0xcfcd8d40:     0xcfcd8db0 (no one points to 0xcfcd8d40, so we rule it out)
0xcfcd8d60:     0xcfcd8db0
0xcfcd8d78:     0xcfcd8e28 (no one points to 0xcfcd8d78)
0xcfcd8dd4:     0xcfcd8e28 (no one points to 0xcfcd8dd4)
0xcfcd8e30:     0xcfcd8e28

0xcfcd8db0:     0xcfcd8e60
0xcfcd8dd0:     0xcfcd8e60 (no one points to 0xcfcd8dd0)
0xcfcd8e28:     0xcfcd8e60

0xcfcd8e60:     0xcfcd8ec0

0xcfcd8ec0:     0xcfcd8f40

0xcfcd8f40:     0xcfcd8fa0

0xcfcd8fa0:     0xbfbfed5c

that makes it looks like this:

    0xcfcd8dcc=0xcfcd8e60   0xcfcd8d7c=0xcf99200c   0xcfcd8d30=0xc0317773
               \                     /                       /
                0xcfcd8e30=0x00000001          0xcfcd8d60=0xc0317773
                          |                             /
                0xcfcd8e28=0x00000000   0xcfcd8db0=0xc0102d06
                           \                     /
                            0xcfcd8ec0=0xc030ca86
                                      |
                            0xcfcd8f40=0xc03a1e3b
                                      |
                            0xcfcd8fa0=0xc0100c6b
                                      |
                            0xbfbfed5c=(a user space address)


that's the address of the suspected ebp value and then the return
address directly following the ebp value from the stack (with the
actual suspected ebp value below).

>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!

gdb says:

0xc0100c6b: No source file
0xc03a1e3b: syscall_plain()
0xc030ca86: sys___sysctl()
0xc0102d06: No source file
0xc0317773: (after the call to cpu_reboot() in panic())
0xc0317773: (after the call to cpu_reboot() in panic())
0xcfcd8e60: No source file
0xcf99200c: No source file

okay...what next?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."