xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#918 closed defect (fixed)

windows 0.15.4 client hangs on control-c disconnect after changing resolution

Reported by: alas Owned by: alas
Priority: critical Milestone: 0.16
Component: client Version: 0.15.x
Keywords: windows, client resolution change, sigint Cc:

Description

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)))

Change History (7)

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

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.

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by 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).

comment:4 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Priority: majorcritical
Status: assignednew

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.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 4 years ago by 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.

comment:6 Changed 4 years ago by 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.

comment:7 Changed 4 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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)

Last edited 4 years ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.