[Xcb] How to cleanly terminate an xcb connection?

Uli Schlachter psychon at znc.in
Wed Oct 13 15:20:22 UTC 2021


Hi,

Am 12.10.21 um 18:00 schrieb Carlo Wood:
> Apparently I am not allowed to just call xcb_disconnect.
> What is the correct way to terminate a connection so that these
> invalid memory accesses won't happen?

short answer: xcb_disconnect() is not thread-safe. You must not be using
the connection from other threads at the same time.

For example, Qt solves this by setting a variable "please exit",
creating a new window, and then sending an event to this window. The
code that waits for events then wakes up and sees that the variable was
set. Look for "CloseConnection" in [0] for details.

[0]:
https://github.com/qt/qtbase/blob/f7a4a79c62daeba9ab5545c5e0a1f36d5e1fce6b/src/plugins/platforms/xcb/qxcbeventqueue.cpp

(In line 367 you can find the nice comment "A hack to close XCB
connection. Apparently XCB does not have any APIs for this?" :-) )

> PS I also get an error during start up:
[...]
> Really strange :/ Why would xcb_flush send uninitialized data over the socket?

No idea, but you could try adding more calls to xcb_flush() in your code
to narrow down which request sending causes this.

A random example on how this can happen: The Qt code above uses
memset(&event, 0, sizeof(event)) on an xcb_client_message_event_t before
sending this event. If you don't do that, you might end up sending
uninitialised data.

I am not saying that libxcb does not cause this, but at least I'd be
surprised about this. Most likely something tells libxcb to send some
uninitialised bytes to the X11 server.

Cheers,
Uli
-- 
<alanc> I think someone had a Xprint version of glxgears at one point,
    but benchmarking how many GL pages you can print per second
    was deemed too silly to merge


More information about the Xcb mailing list