xpra icon
Bug tracker and wiki

Opened 7 weeks ago

Closed 3 weeks ago

#1430 closed defect (fixed)

X11 crash during connection setup

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: critical Milestone: 2.0
Component: server Version: trunk
Keywords: x11 Cc:

Description

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?

Change History (5)

comment:1 Changed 5 weeks ago by Antoine Martin

Resolution: worksforme
Status: newclosed

Haven't seen it since.

comment:2 Changed 3 weeks ago by Antoine Martin

Re-opened with more details here: ticket:1456#comment:5.

comment:3 Changed 3 weeks ago by Antoine Martin

Resolution: worksforme
Status: closedreopened

Found the problem: we're querying the server x11 info from the wrong thread, fix incoming.

comment:4 Changed 3 weeks ago by Antoine Martin

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?

comment:5 Changed 3 weeks ago by Antoine Martin

Resolution: fixed
Status: reopenedclosed

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
Note: See TracTickets for help on using tickets.