Sometimes duplicate zombie client windows are left behind

[Jono Bacon]

I have noticed that sometimes when killing the GUI from the command line some zombie windows are still lying around. This happened recently and I saw this output:

^CTraceback (most recent call last):
  File "/usr/share/quickly/templates/ubuntu-application/run.py", line 73, in <module>
    subprocess.call(command_line, env=env)
  File "/usr/lib/python2.7/subprocess.py", line 493, in call
Traceback (most recent call last):
  File "/usr/bin/quickly", line 101, in <module>
    exit(main())
  File "/usr/bin/quickly", line 86, in main
    return(command.launch(os.getcwd(), command_args, opt_template))
  File "/usr/lib/python2.7/dist-packages/quickly/commands.py", line 546, in launch
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 1291, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "/usr/lib/python2.7/subprocess.py", line 478, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt
    [self.command] + command_args, cwd=project_path)
  File "/usr/lib/python2.7/subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 1291, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "/usr/lib/python2.7/subprocess.py", line 478, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt
jono@forge2:~/source/ubuntu-accomplishments-system$ Traceback (most recent call last):
  File "/home/jono/source/ubuntu-accomplishments-system.old/accomplishments/gui/base/Window.py", line 117, in on_destroy
    def on_destroy(self, widget, data=None):
KeyboardInterrupt

[Rafał Cieślak (rafalcieslak256)]

This is a tricky one. We are unable to catch the KeyboardInterrupt from main.py, as it gets lost in the Gtk's separate thread. We might use a signal handler for SIGINT, and use it to hide and destroy the window, but it will not work, as hiding/destroying widgets requires a Gtk iteration, which we'll be unable to trigger due to the order of how Python's "pending calls" will be proceeded, and at the time we execute the signal handler, the GUI will have already received a KeyboardInterrupt, which causes it to stop working.

The best way I've found it to add
    signal.signal(signal.SIGINT, signal.SIG_DFL)
to main(), it instructs the app to call the default signal handler, when it gets the SIGINT.
This actually closes the window and stops the program completely. However, this will not prevent the Gtk thread from complaining about handled KeyboardInterrupt in the standard output, because that thread will receive the interrupt first. All in all, that's not a minor problem, just an ugly traceback when pressing Ctrl+C.

I've linked in a branch that demonstrates this solution.

[Jono Bacon (jonobacon)]

I think this provides a good fix for this bug: we can always deal with the stdout output later if needed, but I am not as bothered about that as much as most users will start the app from an icon or .desktop file. Thanks, Rafal!