From owner-freebsd-hackers Sat Apr 3 17:21:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 50AEC14BDB for ; Sat, 3 Apr 1999 17:21:47 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA25927; Sun, 4 Apr 1999 10:49:50 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA04237; Sun, 4 Apr 1999 10:49:48 +0930 (CST) Message-ID: <19990404104947.N2142@lemis.com> Date: Sun, 4 Apr 1999 10:49:47 +0930 From: Greg Lehey To: Warner Losh , Bob Bishop Cc: hackers@FreeBSD.ORG Subject: Re: Any way to... References: <199904032206.PAA50844@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199904032206.PAA50844@harmony.village.org>; from Warner Losh on Sat, Apr 03, 1999 at 03:06:27PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 3 April 1999 at 15:06:27 -0700, Warner Losh wrote: > In message 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 : movb 0xf5(%ebx),%al frame 1 at 0xf68bcf20: ebp f68bcf4c, eip 0xf014a860 : addl $0x10,%esp frame 2 at 0xf68bcf4c: ebp f68bcf60, eip 0xf014a538 : leave frame 3 at 0xf68bcf60: ebp f68bcfb4, eip 0xf021d7a7 : movl %eax,%edi (kgdb) defproc 110 110 f68b4260 f6da2000 0 0 110 000084 2 xntpd frame 0 at 0xf6da3de4: ebp f6da3e00, eip 0xf015234d : movb 0xf5(%ebx),%al frame 1 at 0xf6da3e00: ebp f6da3f60, eip 0xf015bdb4 : movl %eax,%esi frame 2 at 0xf6da3f60: ebp f6da3fb4, eip 0xf021d7a7 : 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 : movb 0xf5(%ebx),%al frame 1 at 0xf6da6e00: ebp f6da6f60, eip 0xf015bdb4 : movl %eax,%esi frame 2 at 0xf6da6f60: ebp f6da6fb4, eip 0xf021d7a7 : movl %eax,%edi (kgdb) defproc 2 2 f68b4260 f68bd000 0 0 0 000604 2 pagedaemon frame 0 at 0xf68bef64: ebp f68bef80, eip 0xf015234d : movb 0xf5(%ebx),%al frame 1 at 0xf68bef80: ebp f68bef9c, eip 0xf01fdc1f : addl $0x10,%esp frame 2 at 0xf68bef9c: ebp f68befb0, eip 0xf0142d4a : pushl (%ebx) frame 3 at 0xf68befb0: ebp f02f1ff4, eip 0xf0210748 : addl $0x4,%esp (kgdb) You can then look at individual stack frames: (kgdb) fr 2 frame 2 at 0xf68bef9c: ebp f68befb0, eip 0xf0142d4a : pushl (%ebx) Called from f0210748, stack frame at f02f1ff4 last 20 local variables: 0xf68bef60 : 0x000b1d03 0xf68bef80 0xf015234d 0x80000000 0xf68bef70 : 0xf0142d18 0x00008000 0xf232dad8 0xc00f54da 0xf68bef80 : 0xf68bef9c 0xf01fdc1f 0xf0274978 0x00000004 0xf68bef90 : 0xf0257390 0x000001f4 0xf0274938 0xf68befb0 0xf68befa0 : 0xf0142d4a 0xf68b6df7 0xf025722c 0xf0274938 call parameters: 0xf68befb8 : 0xf0274938 0xf0403000 0x00008000 0x00008000 0xf68befc8 : 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