I've seen this a few times - usually when there is already an active connection and we take over:
setting keymap: rules=evdev, model=pc105, layout=gb,us,gb [xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. python: xcb_io.c:165: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
It looks like we're either accessing the X11 code from the wrong thread or we're just not flushing something (xsync / xswallow).
It could be the cleanup code for the old connection doing an X11 call?
r14996 (backport in r14997) try to make the keyboard code safer using xsync. Maybe this will be enough?
Haven't seen it since.
Re-opened with more details here: ticket:1456#comment:5.
Found the problem: we're querying the server x11 info from the wrong thread, fix incoming.
Fixed in r15220, backport in r15221.
I still want to verify the connection cleanup codepath as this may get triggered from the IO threads in some cases?
Verified the cleanup paths:
CONNECTION_LOST is processed via idle_add so it is safe (only maybe it should be done in the handlers and not in the protocol layer)
disconnect_client and force_disconnect use disconnect_protocol and CONNECTION_LOST
cleanup_source calls the server source close method, which calls cleanup on all the window sources: that code uses idle_add for the gobject signal handlers, r15225 does the same for the dbus server just in case
last_client_exited which is called for some cleanups, is already called via idle_add
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1430