Date: Sun, 4 Apr 1999 10:49:47 +0930 From: Greg Lehey <grog@lemis.com> To: Warner Losh <imp@harmony.village.org>, Bob Bishop <rb@gid.co.uk> Cc: hackers@FreeBSD.ORG Subject: Re: Any way to... Message-ID: <19990404104947.N2142@lemis.com> In-Reply-To: <199904032206.PAA50844@harmony.village.org>; from Warner Losh on Sat, Apr 03, 1999 at 03:06:27PM -0700 References: <l03020914b32c241fe04f@[194.32.164.2]> <199904032206.PAA50844@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 3 April 1999 at 15:06:27 -0700, Warner Losh wrote:
> In message <l03020914b32c241fe04f@[194.32.164.2]> Bob Bishop writes:
> : >... get a kernel stack trace of a running process?
> : gdb -k /kernel /dev/mem, I expect
>
> How to I get that from gdb? gdb will tell me where in the kernel
> things are now, but not where a process may be sleeping or stuck.
Take a look at /usr/src/sys/modules/vinum/.gdbinit.kernel. It
contains a number of (barely documented) macros for looking at other
processes. Unfortunately, I've just tried them on a running system,
and they don't work. I'll fix them and let you know. In principle,
the defproc macro will give you a back trace of the process you
specify. Here's a case from a remote debug session:
(kgdb) ps
pid proc addr uid ppid pgrp flag stat comm wchan
...
133 f68b5860 f6dbb000 0 1 133 000084 3 rpc.statd select f029ce70
130 f68b59c0 f6db7000 0 125 125 000084 3 nfsd nfsd f0efd600
129 f68b5b20 f6db4000 0 125 125 000084 3 nfsd nfsd f0efd800
128 f68b5c80 f6db1000 0 125 125 000084 3 nfsd nfsd f0efda00
127 f68b5de0 f6dae000 0 125 125 000084 3 nfsd nfsd f0ec4600
125 f68b5f40 f6dab000 0 1 125 000084 3 nfsd accept f648d036
122 f68b60a0 f6da8000 0 1 122 000084 3 mountd select f029ce70
114 f68b6200 f6da5000 1 1 114 000184 3 portmap select f029ce70
110 f68b6360 f6da2000 0 1 110 000084 2 xntpd
100 f68b6620 f6d8c000 0 1 100 000084 2 syslogd
4 f68b6a40 f68c1000 0 0 0 000204 2 syncer
3 f68b6ba0 f68bf000 0 0 0 000204 3 vmdaemon psleep f0293bb0
2 f68b6d00 f68bd000 0 0 0 000604 2 pagedaemon
1 f68b6e60 f68bb000 0 0 1 004084 3 init wait f68b6e60
0 f029c0fc f02f0000 0 0 0 000204 2 swapper
(kgdb) defproc 1
1 f68b4260 f68bb000 0 0 1 004084 3 init wait f68b6e60
frame 0 at 0xf68bcf04: ebp f68bcf20, eip 0xf015234d <tsleep+365>: movb 0xf5(%ebx),%al
frame 1 at 0xf68bcf20: ebp f68bcf4c, eip 0xf014a860 <wait1+804>: addl $0x10,%esp
frame 2 at 0xf68bcf4c: ebp f68bcf60, eip 0xf014a538 <wait4+16>: leave
frame 3 at 0xf68bcf60: ebp f68bcfb4, eip 0xf021d7a7 <syscall+391>: movl %eax,%edi
(kgdb) defproc 110
110 f68b4260 f6da2000 0 0 110 000084 2 xntpd
frame 0 at 0xf6da3de4: ebp f6da3e00, eip 0xf015234d <tsleep+365>: movb 0xf5(%ebx),%al
frame 1 at 0xf6da3e00: ebp f6da3f60, eip 0xf015bdb4 <select+876>: movl %eax,%esi
frame 2 at 0xf6da3f60: ebp f6da3fb4, eip 0xf021d7a7 <syscall+391>: movl %eax,%edi
(kgdb) defproc 114
114 f68b4260 f6da5000 1 0 114 000184 3 portmap select f029ce70
frame 0 at 0xf6da6de4: ebp f6da6e00, eip 0xf015234d <tsleep+365>: movb 0xf5(%ebx),%al
frame 1 at 0xf6da6e00: ebp f6da6f60, eip 0xf015bdb4 <select+876>: movl %eax,%esi
frame 2 at 0xf6da6f60: ebp f6da6fb4, eip 0xf021d7a7 <syscall+391>: movl %eax,%edi
(kgdb) defproc 2
2 f68b4260 f68bd000 0 0 0 000604 2 pagedaemon
frame 0 at 0xf68bef64: ebp f68bef80, eip 0xf015234d <tsleep+365>: movb 0xf5(%ebx),%al
frame 1 at 0xf68bef80: ebp f68bef9c, eip 0xf01fdc1f <vm_pageout+419>: addl $0x10,%esp
frame 2 at 0xf68bef9c: ebp f68befb0, eip 0xf0142d4a <kproc_start+50>: pushl (%ebx)
frame 3 at 0xf68befb0: ebp f02f1ff4, eip 0xf0210748 <fork_trampoline+8>: addl $0x4,%esp
(kgdb)
You can then look at individual stack frames:
(kgdb) fr 2
frame 2 at 0xf68bef9c: ebp f68befb0, eip 0xf0142d4a <kproc_start+50>: pushl (%ebx)
Called from f0210748, stack frame at f02f1ff4
last 20 local variables:
0xf68bef60 <daemonq+92956848>: 0x000b1d03 0xf68bef80 0xf015234d 0x80000000
0xf68bef70 <daemonq+92956864>: 0xf0142d18 0x00008000 0xf232dad8 0xc00f54da
0xf68bef80 <daemonq+92956880>: 0xf68bef9c 0xf01fdc1f 0xf0274978 0x00000004
0xf68bef90 <daemonq+92956896>: 0xf0257390 0x000001f4 0xf0274938 0xf68befb0
0xf68befa0 <daemonq+92956912>: 0xf0142d4a 0xf68b6df7 0xf025722c 0xf0274938
call parameters:
0xf68befb8 <daemonq+92956936>: 0xf0274938 0xf0403000 0x00008000 0x00008000
0xf68befc8 <daemonq+92956952>: 0xf02106b0 0xf02f1ff4 0xf0215375 0xf0000000
(kgdb)
It's not as comfortable as real gdb, but it's better than nothing.
> Actually, looking at the "top" output, shows that pppd is stuck in
> "select" state, so getting a kernel stack trace of that wouldn't be
> helpful.
Depends on where you get the trace from. The real problem is that you
can't trace back into a non-executing processes user space, because it
isn't mapped (can some VM guru tell me how to locate the pages?).
Anyway, as I say, some buglet stops it from working on my machine with
/dev/mem, though maybe it'll work for you. I'll investigate what's
going on, but it won't be immediately.
Greg
--
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990404104947.N2142>