Re: Examining kernel thread state at run-time
Re: Examining kernel thread state at run-time
- Subject: Re: Examining kernel thread state at run-time
- From: Sam Vaughan <email@hidden>
- Date: Fri, 9 Feb 2007 10:31:14 +1100
On 08/02/2007, at 6:08 PM, Michael Smith wrote:
On Feb 7, 2007, at 3:35 PM, Sam Vaughan wrote:
I remember being told by an Apple engineer quite some time back
that there was an internal tool that only worked on Intel that did
just this. I asked about it at WWDC last year and was told to
look for "stackshot". I distinctly remember the guy suggesting I
"man stackshot". Now that I try it I can't find it, so hopefully
someone can reply with more details.
It's an internal tool, I'm sorry. Your best bet is going to be to
NMI, connect with GDB, 'showallstacks' and continue. I realise
this isn't the greatest.
We needed something that could be run in the test labs, QA and even
by engineers at customers' sites if deadlocks occurred. That ruled
out two machine debugging. To cap it off, with clustered file
systems the state of the system as a whole is perturbed by an NMI
because it kills the heartbeating that's maintaining membership quorum.
Anyway, a little birdie reminded me that an approaching species of
spotted operating system might be the place to be looking for stackshot.
Being able to get run-time backtraces of all your kernel threads
is _really_ useful.
With continuations it helps less than you might like, though
typically threads that are asleep in "common" locations are less
interesting.
True, but if you're looking for deadlocked threads then there are
usually a couple of very interesting backtraces in the output.
Thanks Mike,
Sam
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden