On vrijdag, apr 4, 2003, at 03:35 Europe/Brussels, jmagee@apple.com 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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.