Re: P_WEXIT
Re: P_WEXIT
- Subject: Re: P_WEXIT
- From: Terry Lambert <email@hidden>
- Date: Fri, 15 Dec 2006 19:24:38 -0800
On Dec 15, 2006, at 7:04 PM, Joseph Oreste Bruni wrote:
On Dec 15, 2006, at 7:35 PM, Terry Lambert wrote:
On Dec 15, 2006, at 9:20 AM, Quinn wrote:
At 20:24 -0700 13/12/06, Joseph Oreste Bruni wrote:
On my test system, I can start and kill my process all day long
and never reproduce this. In production, where the system runs
for weeks, the condition occurs...
You might want to set up kernel core dumps on your production
machine. When you get a stuck process, you can press NMI to dump
a kernel core. From that you could look at the state of the stuck
process.
<http://developer.apple.com/technotes/tn2004/tn2118.html>
I concur; I meant to respond to this earlier, and my opinion is
that there's nothing for this except the kernel debugger.
If you have a second machine to debug with, then that wold be
better thn a core dump server (unless there was an intent to send
the core to Apple in a bug report), since a lot of the kgmacros
that would be useful for debugging this issue do not work on core
files because of gdb limitations that have not been addresses
(specifically local shadow register state being used in place of
image register state so things like "switchtoact" actually switch).
-- Terry
I had already opened a bug (4680335), but it was closed with a
"behaves correctly" status. Create a new one or can I file this
under the original?
I figured this would eventually end up being a kernel problem since
the basic outline of my program is:
1) create N number of threads at startup
2) do network and file I/O for days, weeks, etc.
3) receive SIGTERM
4) join with N number of threads
5) exit()
6) hang in kernel who thinks there are still more threads
7) ???
I've had to send kernel dumps before so I'm familiar with the
process. (Bug in original PCI fibrechannel card in G5 Xserve.)
Now I get to figure out how to generate an NMI on the headless
Xserve...
The guy in charge of the developer interaction shut it down after 7
days of not hearing anything to a ping. The statement in it is "Will
re-open if Developer writes back in.".
If you set the debug flags for kernel debugging (e.g. 0x144),
momentarily hitting the power button will generate the require NMI to
drop you into the debugger (or send the core to a dump server, if you
have a dump server configured, instead, in the flags), rather than
putting the machine to sleep.
Let me say up front that I don't believe this is a kernel problem, and
the "showallstacks" command should confirm that there are still stacks
running in the process. You may end up (if it has already been taken
off the active process list) having to track down the task from the
zombie list, if it doesn't show up in the task list - meaning it won't
show in the "showallstacks".
If that's the case, then walk the list to find the process, then look
in that for the task, and then "showtaskstacks 0xdsfgsdfg", where the
argument is the hex address of the task.
Also, if that's the case, it's probably easier to NMI before you shut
down the process, get the information from "showalltasks",
"c" (continue) it, cause the problem, NMI it again, and then use the
information you got previously for the "showtaskstacks"
There will be at least one thread in a strange state, and whatever it
(or they, if there's more than one) blocks on is the source of your
problem.
It's be a lot easier if I could attach the machine (8-)), but I really
don't have the hardware or software resources necessary to recreate
your problem and diagnose it in house.
-- Terry
_______________________________________________
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
| References: | |
| | >P_WEXIT (From: Joseph Oreste Bruni <email@hidden>) |
| | >Re: P_WEXIT (From: Quinn <email@hidden>) |
| | >Re: P_WEXIT (From: Terry Lambert <email@hidden>) |
| | >Re: P_WEXIT (From: Joseph Oreste Bruni <email@hidden>) |