Darwin kernel hang -- how to diagnose?

I have program that somehow gets the process into uninterruptible
wait status (U is in the ps -x display), and the process is hung
and unkillable. The machine then hangs on shutdown requiring a
power cycle to restart.

I doubt Apple will provide any help in diagnosing this, so are there
any tools to let a programmer who has never done kernel programming
at least find out where in the kernel the process is hung? If I can
find say a sequence of section (2) calls that cause this, then at
least I can avoid that sequence; or do more thread locking. Or
something. At the moment I have no idea where to start.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
If your job was as meaningless as theirs, wouldn't you go crazy too?

In article <134mmfbcuj47q79 RemoveThis @corp.supernews.com>,
SM Ryan <wyrmwif RemoveThis @tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

> I have program that somehow gets the process into uninterruptible
> wait status (U is in the ps -x display), and the process is hung
> and unkillable. The machine then hangs on shutdown requiring a
> power cycle to restart.
>
> I doubt Apple will provide any help in diagnosing this, so are there
> any tools to let a programmer who has never done kernel programming
> at least find out where in the kernel the process is hung? If I can
> find say a sequence of section (2) calls that cause this, then at
> least I can avoid that sequence; or do more thread locking. Or
> something. At the moment I have no idea where to start.
>

Hi

1) try running "sample" on your hung process, that should tell you where
the process is hung up. I don't know if "sample" is on your system
without dev tools installed. Open a terminal window and type "sample",
if it's installed you'll get directions.

2) ssh into your machine from another machine, execute "sudo tail -f
/var/log/system.log" and see if the kernel is logging failure messages
in the system log. Depending on where in your shutdown sequence the
hang is occurring your ssh session may get terminated before you see
anything useful.

3) Boot in verbose (command-V) or single user mode (command-S during
startup). The kernel may be logging failure messages that you're not
seeing and they'll show up in both of these modes. Verbose would be
where I start.

4) File a bug.

Cheers,
-H.

--
To reply via email, replace "LastNameHere" with my last name.