Bug 339494

The process still exists, otherwise KWin would not be able to find its name :)

Client destruction after xkill invocation may be coincidental.
Notice that kwin tries SIGTERM for local clients and uses "xon" (which i haven't even installed...) for remote ones (rather than XKillClient)

Possible reasons:
a) the client may require a more convincing SIGKILL
b) the client process may belong to a different user ("ubuntu-release-upgrader" sounds like root)
c) client indeed lost connection to server.

@Christoph
the application name is just the "resourceClass()" - we do not look up /proc (portability, i assume)
For a remote client or a completely screwed X11 server, it *would* be possible to have a window for a client with lost connection.
Since I however doubt either, I prefer answers a or b ;-)

I forgot to mention: I ran "ps 4176" to see what process was frozen, but "ps" couldn't find it, so I'm pretty sure the process was in fact gone.

Well, we cannot "fail" to kill a process that is gone.
You didn't happen to check whether there was another PID for "ubuntu-release-upgrader", did you?

There was a "dpkg" process still running, which might have been the cause.

I actually came up with a repro:

"""
#include <unistd.h>
#include <QApplication>
#include <QMainWindow>

int main(int argc, char *argv[]) {
  QApplication app(argc, argv);

  QMainWindow w;
  w.show();

  if (fork() == 0) {
    sleep(60);
    exit(0);
  }

  alarm(3);

  return app.exec();
}
"""

The application forks, then crashes. That's probably what ubuntu-release-upgrader did.

Many thanks.

The reason is that _NET_WM_PID isn't updated on the window for the fork(), ie. is invalid.

That's a NETWM violation, ie. client (in this case Qt) bug.

xcb_kill_client just breaks the client/server connection, but doesn't actually kill the client (though the client *may* terminate in return), so actually ::kill() is the better variant for local connections and assumed legit PIDs, so we could

if (::kill(pid, SIGTERM) != 0)
   xcb_kill_client(connection(), m_client);

BUT:
a) that doesn't necessarily kill the client
b) we might still kill the wrong process for the false PID :-\

the connection is broken, the window closed - but the demo process is still running.

My 2¢
- This is a client bug.
- If killing the client fails (other than for EPERM), we should tell the user (resolving errno) and OFFER to simply break the client/server connection, WARNING that the process will likely not be killed and suggest to open ksysguard to isolate and kill the process instead.
- Silently breaking the connection is not helpfull at all

----
https://bugreports.qt-project.org/browse/QTBUG-41664

I agree with the 2 cents from previous comment. I wouldn't mind us to improve the experience, in fact we could even open the process ui filtered on the window, but that would introduce a new dependency on the library.

But I would also say that it's not a high priority as it's clearly a client bug if the pid is wrong.

This has been implemented afaict