Date: Mon, 15 Nov 1999 17:32:16 -0500 From: Greg Lehey <grog@mojave.sitaranetworks.com> To: Thomas David Rivers <rivers@dignus.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel debug assistance? Message-ID: <19991115173216.19303@mojave.sitaranetworks.com> In-Reply-To: <199911151603.LAA04493@lakes.dignus.com>; from Thomas David Rivers on Mon, Nov 15, 1999 at 11:03:04AM -0500 References: <199911151603.LAA04493@lakes.dignus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 15 November 1999 at 11:03:04 -0500, Thomas David Rivers wrote: > > I'm trying to track down a problem in 3.3-RELEASE > (which I _think_ might be a linux emu bug that's > crashing the kernel.) > > Anyway - I thought I might ask here for some > kernel debugging assistance... > > I've got a debuggable kernel, with DDB. > > When the panic occurs (which I can readily reproduce) > I drop down into DDB... > > Which is great - right? > > But - IP is 0x0 (or, sometimes 0x80000000) - so the > trace command in DDB (to show the stack traceback) > doesn't seem to work - all I get is the Trap 12 message. That in itself doesn't mean you can't do a backtrace. I'm currently fighting this one: (kgdb) bt #0 0x0 in ?? () #1 0xc0184494 in spec_close (ap=0xc5f9de58) at ../../miscfs/specfs/spec_vnops.c:673 #2 0xc01f804e in ufsspec_close (ap=0xc5f9de58) at ../../ufs/ufs/ufs_vnops.c:1872 #3 0xc01f8521 in ufs_vnoperatespec (ap=0xc5f9de58) at ../../ufs/ufs/ufs_vnops.c:2317 (etc). > Does anyone have any sage words of advice on how to proceed with > tracking this down? At least some neat trick for determining where > the bad branch is taken? The real problem is that you have probably trashed your stack. I'd recommend using remote serial gdb; few people are happy with the level of support provided by ddb. Then you need to guess where it's happening, and set some breakpoints round likely places. It's not easy. The first thing to do would be to establish whether you're in process or interrupt context. If you're in a process context, you can at least find what process it is, and the macros in /usr/src/sys/modules/vinum/.gdbinit.kernel should help you determine what it's doing (sorry, the only documentation on these macros is the source code, including the gdb 'help user' command). Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?19991115173216.19303>