Date: Thu, 7 Mar 96 11:01:51 MET From: Greg Lehey <lehey.pad@sni.de> To: davidg@Root.COM Cc: hackers@freebsd.org (Hackers; FreeBSD) Subject: Re: using ddb to debug a double-panic? Message-ID: <199603071005.LAA20629@nixpbe.pdb.sni.de> In-Reply-To: <199603020859.AAA13750@Root.COM>; from "David Greenman" at Mar 02, 96 12:59 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Is there a simple sequence I can type into ddb to switch stack pointers and >> frames so I can do a "where" to see where I was when the first panic occured? > > I thought about writing some extensions to "trace" to allow it to apply a > (operator supplied) 'stack offset' that would be used to adjust the pushed FPs > (for precisely the purpose of what you're requesting above). ...but I haven't > gotten around to this yet. For now, I just use 'curpcb' to find the stack that > [might] have been in use at the time of the double fault, and then munge > around in the stack manually (yes, I know, yuck). Of course if there was no > process running at the time, you'll want to look at tmpstk instead. > This code definately code use some work - I just wanted to catch the case > in the first place so that machines didn't just "wedge"...and then have at > least a snowball's chance of figuring out the cause. I'm not happy with the > way that the double fault TSS currently works (using IdlePTD, etc), but I > haven't had any time to implement it better. I've been thinking about improving ddb. About 4 years ago, I wrote a similar kernel debugger for BSD/386, and was thinking of incorporating some of its features into ddb. One of the things it could do was exactly this kind of stack trace (well, it supplied other information as well). I won't get round to doing it until May, though. Does anybody else have ideas about improving ddb? Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603071005.LAA20629>