Xpra: Ticket #918: windows 0.15.4 client hangs on control-c disconnect after changing resolution

Testing with windows 8.1 client 0.15.4 r9951 against fedora 20 0.15.4 r9951 server - after changing the resolution of the local client device, control-c disconnection leaves client hung about half the time, requiring use of task manager to close xpra.

Repro-ing with -d client client-side, I get the following:

2015-07-16 19:02:37,874 received console event CTRL_C
2015-07-16 19:02:37,874 disconnect_and_quit(0, CTRL_C)
2015-07-16 19:02:37,874 UIXpraClient.cleanup()
2015-07-16 19:02:37,874 XpraClientBase.cleanup() protocol=Protocol(None)
2015-07-16 19:02:37,874 disconnect_and_quit: protocol_closed()
2015-07-16 19:02:37,874 UIXpraClient.cleanup() calling <class 'xpra.client.gtk_base.gtk_keyboard_helper.GTKKeyboardHelper'>.cleanup()
2015-07-16 19:02:37,874 UIXpraClient.cleanup()
2015-07-16 19:02:37,874 UIXpraClient.cleanup() calling <class 'xpra.clipboard.translated_clipboard.TranslatedClipboardProtocolHelper'>.cleanup()
2015-07-16 19:02:37,874 XpraClientBase.cleanup() protocol=None
2015-07-16 19:02:37,888 UIXpraClient.cleanup() calling <class 'xpra.platform.win32.win32_tray.Win32Tray'>.cleanup()
2015-07-16 19:02:37,888 UIXpraClient.cleanup() calling <class 'xpra.client.gtk_base.gtk_keyboard_helper.GTKKeyboardHelper'>.cleanup()
2015-07-16 19:02:37,888 UIXpraClient.cleanup() calling <class 'xpra.clipboard.translated_clipboard.TranslatedClipboardProtocolHelper'>.cleanup()
2015-07-16 19:02:37,888 UIXpraClient.cleanup() calling <class 'xpra.platform.win32.win32_tray.Win32Tray'>.cleanup()
2015-07-16 19:02:37,888 UIXpraClient.cleanup() calling <class 'xpra.platform.win32.win32_notifier.Win32_Notifier'>.cleanup()
2015-07-16 19:02:37,888 UIXpraClient.cleanup() calling <class 'xpra.client.gtk2.tray_menu.GTK2TrayMenu'>.cleanup()
2015-07-16 19:02:37,888 UIXpraClient.cleanup() calling <class 'xpra.platform.win32.gui.ClientExtras'>.cleanup()
2015-07-16 19:02:37,888 error during win32 events cleanup: (5, 'DestroyWindow', 'Access is denied.')
2015-07-16 19:02:37,888 error on <class 'xpra.platform.win32.gui.ClientExtras'> cleanup
Traceback (most recent call last):
  File "xpra\client\ui_client_base.pyc", line 375, in cleanup
  File "xpra\platform\win32\gui.pyc", line 517, in cleanup
  File "xpra\platform\win32\win32_events.pyc", line 101, in cleanup
error: (1412, 'UnregisterClass', 'Class still has open windows.')
2015-07-16 19:02:37,888 UIXpraClient.cleanup() calling <class 'xpra.codecs.video_helper.VideoHelper'>.cleanup()
2015-07-16 19:02:37,888 destroy_all_windows() destroying 1 / GLClientWindow(1 : gtk2.GLWindowBacking(1, (499, 316), None))
2015-07-16 19:02:37,888 destroy_window(1, GLClientWindow(1 : gtk2.GLWindowBacking(1, (499, 316), None)))


Fri, 17 Jul 2015 02:45:21 GMT - Antoine Martin: owner, status changed

Thanks, I was aware of the bug (on my never ending TODO list), but the UnregisterClass error is a new one I had not seen before.


Fri, 17 Jul 2015 03:50:15 GMT - Antoine Martin:

r9956 should workaround the UnregisterClass, will backport.

As for the more general issue of exit on control-c... In 0.15, I took a different approach to try to make it more reliable: on some platforms we can't rely on the main loop to still be running after receiving a control-c signal, so we now run all the cleanup from that event handler (whichever thread that may be), which works most of the time (including with GTK3 and all the platforms I tested), but clearly not always.

Maybe we should do something else, like start a new delayed thread to run the cleanups if the main loop doesn't run them. Will see what I can do.


Mon, 20 Jul 2015 17:14:57 GMT - Antoine Martin:

I've managed to hang the client a couple of times, and the last message before the hang was clipboard related... (this could explain #870?) Maybe the clipboard really dislikes the threading problems, maybe we should just not bother trying to store the clipboard on exit (which is what the cleanup code does).


Fri, 24 Jul 2015 16:05:23 GMT - Antoine Martin: owner, priority, status changed

This also manifested itself on X11 clients with:

failed to remove event receivers: XError: 3

r10036 fixes the problems seen with trunk... which were actually a bit different. (+ fixup in r10038) I think that the clipboard hang was just because we called GTK from the wrong thread, so this may not solve #870, unfortunately.

The fix for v0.14.x and v0.15.x is in r10037 (only a one-liner change), maybe a recent fix to the network layer made it more likely that we ended up calling the cleanup code from the (wrong) network thread. With this fix, sending a control-c to the client should always exit the first time and within about a second or so, the server should print something like: Disconnecting client ...: client request.

@afarr: does that fix things for you? I would like to release new stable versions if this fix is valid. It is also worth also double checking #870. I have uploaded win32 beta builds of all branches, including trunk.


Mon, 27 Jul 2015 05:24:29 GMT - Antoine Martin:

I may have been wrong about failed to remove event receivers, I think this can happen even without us doing anything wrong with threading during cleanup, so r10067 now tries it 5 times and avoids using "warning" log level until the 5th time.


Wed, 29 Jul 2015 02:22:26 GMT - alas:

Testing windows 8.1 client 0.16.0 r10076 against a fedora 21 server 0.16.0 r10107 (or 9562, my svn updates in builds is still not being reflected in my sessioninfo)...

In any case, control-c seems to be working as expected client side.

Server-side I'm seeing the following, but I suspect it has something to do with not configuring printing (though, it seems odd to me to be getting errors codes unless the setup has problems):

2015-07-28 19:18:30,410 client has requested disconnection: CTRL_C
2015-07-28 19:18:30,411 Disconnecting client '10.0.11.137:51812': client request
lpadmin: The printer or class does not exist.
2015-07-28 19:18:30,446 xpra client disconnected.
lpadmin: The printer or class does not exist.
2015-07-28 19:18:30,458 lpadmin failed and returned error code: 1
2015-07-28 19:18:30,459 you may want to check that this user has the required permissions for using this command

Since I assume these error bits are not relevant to this ticket, we can probably close this... but I wanted to pass those by you in case I'm missing something.


Wed, 29 Jul 2015 02:24:55 GMT - Antoine Martin: status changed; resolution set

my svn updates in builds is still not being reflected in my sessioninfo


Then something is wrong with your build environment or deployment. Fix that first.


The lpadmin errors are documented on the wiki: wiki/Printing (on Fedora you need to be part of the "sys" group and disable selinux)


Sat, 23 Jan 2021 05:09:45 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/918