On Fri, 14 Sep 2012 21:33:30 UTC, James Moe
<
jimoe...@sohnen-moe.com> wrote:
Hi,
> I note that it has the same Block ID as thread 5.
> What is the following output from PSTAT telling me?
It's telling you that you should be using pmdf to figure out what
thread #4 exists. :-)
> Thread
> ID Priority State Block ID Owned Semaphores
> 01 0200 Block FDEF62A4
> 02 0200 Block FDEFE654
> 04 0200 Block FFCA0064 <== mystery thread
> 05 0201 Block FFCA0064
> 06 0200 Block FFF3FB04
> 07 0200 Block 0820019E
> 08 0200 Block FDF01D7C
> 0C 0200 Block FDF01D34
> 0D 0200 Block FDF01CEC
The reason it has the same block id is because it is waiting for the
same resource. Given that the blockid looks like it's somewhere in
the kernel heap, it probably represents a semaphore or maybe a file
handle.
Once you have pmmail in a state where the mystery thread exists, use
my pdumpctl to force an extended dump. This may capture enough data
to work with.
Open up the dump file in pmdf. Install .sym files as needed. Use the
.p command to see the thread slots. Use the .s to switch to the
mystery threads slot. Use Analyze->Thread->Call gate to find out why
the thread is waiting. Use ln eip to see where the ring 3 code is.
Use k to see the call stack (maybe).
Ask you need more assistance.
Steven
--
---------------------------------------------------------------------
Steven Levine <
ste...@earthlink.bogus.net>
eCS/Warp/DIY etc.
www.scoug.com www.ecomstation.com
---------------------------------------------------------------------