Re: unkillable process ?
Re: unkillable process ?
- Subject: Re: unkillable process ?
- From: Jonas Maebe <email@hidden>
- Date: Fri, 4 Apr 2003 09:31:48 +0200
On vrijdag, apr 4, 2003, at 03:35 Europe/Brussels, email@hidden
wrote:
That "U" means that the process (or more appropriately, one of the
threads in the process) is blocked in the kernel in an
"uninterruptible" state. It is unacceptable for the kernel/drivers to
so mark a thread and then non make forward progress on it. Do you
have any non-standard kernel extensions? What system call was thread
making when it got into this state? You can find the latter by
running the sample tool on the process (or attaching with gdb).
When I have a problem like this, most of the time the process is
blocked in statfs. Yesterday, I had this problem with MPlayer when I
first added a file to its playlist, quit the application, restarted it
and then clicked again on that file in the playlist. kill -9 seems to
work only sporadically in such a case (it seems that the kernel blocks
a long time, then returns and the program immediately tries again, so
the kill only works if you accidentally do it right at a moment the
program isn't blocked in the kernel - it seems to signals aren't
queued). However, attaching with gdb does seem to work consistently, it
seems the ptrace syscall does get queued somehow, so gdb attaches the
first time the system call ends. After you attach, you can do a kill.
FWIW, here's the sample I did yesterday (on MPlayer, I hope it doesn't
wrap too badly):
***
500 Thread_0e03
500 start
500 _start
500 main
500 NSApplicationMain
500 -[NSApplication run]
500 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
500 _DPSNextEvent
500 BlockUntilNextEventMatchingListInMode
500 ReceiveNextEventCommon
500 RunCurrentEventLoopInMode
500 CFRunLoopRunSpecific
500 __CFRunLoopRun
500 __CFRunLoopDoSource1
500 __CFMachPortPerform
500 VNDiskArbHandleMessage
500 ServerToClient_server
500
_XDiskArbDiskAppearedWithMountpoint_rpc
500
DiskArbDiskAppearedWithMountpoint_rpc
500 DiskMountCallback(char*,
unsigned, char*)
500 VNDiskNotification(int,
char*, unsigned, char*, int)
500 MountVolume(char
const*, statfs*, unsigned char)
500 statfs
500 statfs [STACK TOP]
***
I'm not sure why those mount calls are in there, because I didn't mount
a remote volume on this machine. I did mount a volume from this machine
on another one - namely the volume on which the file I had deleted
resided. I don't know whether that had anything to do with it. Anyway,
in this state the program couldn't be killed using kill -9 or with the
force quit command (unless you do it all the time and get lucky).
Jonas
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.