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?
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.
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_LOSTis processed via idle_add so it is safe (only maybe it should be done in the handlers and not in the protocol layer)
cleanup_sourcecalls the server source
closemethod, which calls
cleanupon 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_exitedwhich 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