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>