When I click on "Close Window" button for the unresponsive app, message from window manager shows up offering to kill the non-existent pid. See the screenshot attached. $ ps ax | grep 53455 53625 ?? S 0:00.31 /usr/local/kde4/lib/kde4/libexec/kwin_killer_helper --pid 53455 --hostname localhost --windowname Meld --applicatio 53670 7 S+ 0:00.00 grep 53455 Reproducible: Always
Created attachment 78582 [details] screenshot of a message screenshot
If you can reproduce this, please provide the output of "xprop" on this window (and the actually related PID)
Here is xprop output. Please note, that pid=53455 mentioned there isn't a valid pid. $ xprop _NET_WM_USER_TIME(CARDINAL) = 469991939 _NET_WM_ICON_GEOMETRY(CARDINAL) = 780, 1168, 121, 34 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _NET_WM_DESKTOP(CARDINAL) = 0 _KDE_NET_WM_ACTIVITIES(STRING) = "0e0f6f81-e529-4d56-ad97-da2591f98d96" _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 23, 4 _NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 23, 4 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x780001a bitmap id # of mask for icon: 0x780001d window id # of group leader: 0x7800001 XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 _NET_WM_ICON(CARDINAL) = Icon (22 x 22): <...removed icons as irrelevant...> _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 469693480 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 125829125 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x7800004 WM_CLIENT_LEADER(WINDOW): window id # 0x7800001 _NET_WM_PID(CARDINAL) = 53455 WM_LOCALE_NAME(STRING) = "en_US.UTF-8" WM_CLIENT_MACHINE(STRING) = "eagle.yuri.org" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 668 by 400 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "meld", "Meld" WM_ICON_NAME(STRING) = "Meld" _NET_WM_ICON_NAME(UTF8_STRING) = "Meld" WM_NAME(STRING) = "Meld" _NET_WM_NAME(UTF8_STRING) = "Meld"
Here are the relevant processes: $ ps ax | grep python 3255 ?? S 0:07.69 python /usr/local/kde4/bin/printer-applet (python2.7) 3291 ?? S 0:35.49 /usr/local/bin/python2.7 /usr/local/share/ibus/ui/gtk/main.py 3338 ?? I 0:01.54 python /usr/local/bin/hp-systray -x (python2.7) 3339 ?? S 0:14.83 python /usr/local/bin/hp-systray -x (python2.7) 53545 5 I 0:00.00 python /usr/local/bin/meld xxx.tcl (python2.7) 53546 5 I 0:00.00 python /usr/local/bin/meld xxx.tcl (python2.7) 53547 5 I 0:00.00 python /usr/local/bin/meld xxx.tcl (python2.7) 53548 5 I 0:00.00 python /usr/local/bin/meld xxx.tcl (python2.7) 53549 5 I 0:00.00 python /usr/local/bin/meld xxx.tcl (python2.7) 53550 5 I 0:00.00 python /usr/local/bin/meld xxx.tcl (python2.7) 53551 5 I 0:00.00 python /usr/local/bin/meld xxx.tcl (python2.7) 53552 5 I 0:00.00 python /usr/local/bin/meld xxx.tcl (python2.7) 54017 10 S+ 0:00.00 grep python
The PID provided by the client as window property is the only connection we have - on local Linux, one could attempt a plausibility test on /proc, but that's special case working around a client bug (ping & kill is "nice to have" but totally relies on the clients being nice and exporting the proper PID - KWin only sees windows, not processes) What i suspect is happening is that "meld" (or ultimately python) is somehow forking child processes and then exits the initing parent process, but sets the PID of the latter on one or more windows of the child processes - could also be a matter of updating the property failing due to the hanging client.
Thanks! I brought it up with the meld maintainers. On the other note, it is very weird that there is no reliable way to trace the window to the process without relying on the various apps cooperation and correctness of submitted by them information. Xorg creates windows based on network requests. Those requests come from connections. Connections can be traced to local or remote processes. Every OS has the ability to map pid/file-descriptor to the originating IP or local host/process combination.
(In reply to comment #6) > Connections can be traced to local or remote processes. Well, then just do :-P KWin opens a socket, contacting to the X11 server socket. So does the (other) client (like eg. kwrite, dolphin or konsole - or your python process) -> KWin has no direct relation to the other clients socket. X11 will usually run as root - you're not reading its internals, ever. Now, X11 could theoretically determine the other sockets, on linux (there's actually no guarantee to be able to link a socket to a PID on a local connection on a random OS - X11 is 30 years old and ran on many of them =) inspect /proc to determine the matching PID and tell that or the socket (for self inspection) or IP to everybody who asks, but that part of the X11 protocol is unknown to me. Notice that there's actually XKillClient() (beyond the preferred way to just delete the window and let the client decide what to do in return) just that it doesn't help you for those clients which need a SIGKILL kick in the butt. Stupid question aside: this WM_CLIENT_MACHINE(STRING) = "eagle.yuri.org" is the local machine, yes?
Yes, this is the local machine. The way I see it, X lacks API to access connection info. The most it could give is the owning connection's FD in Xorg process. Then, there are (or aren't) OS-specific ways to determine the connection origin. There are definitely ways on Linux/FreeBSD. But all this is a long shot way beyond the scope of this PR or kde, of course.
It looks like python is at fault in this case. Here is the python PR for this issue: http://bugs.python.org/issue17622