Details
-
Bug
-
Resolution: Done
-
P1: Critical
-
5.2.1, 5.3.0 Beta1
-
6977700bed929c7f1a20192d07a06abc2fdca278 in qtbase
Description
I've heard from two people that they're getting the following assert:
qtcreator: xcb_conn.c:186: write_vec: Assertion `!c->out.queue_len' failed.
One of them was using QtCreator 3.1.0 beta (aka 3.0.82) on Qt 5.2.1.
To sum up all the comments below:
There are two code paths which can be used to communicate with libxcb. One is from QWidget and friends in the GUI thread. e.g. xcb_flush() can be called on geometry changes as seem in Pasi's backtrace. The other one is via the OpenGL library from the renderer thread. Such a backtrace can be seen in Oleg's comments where it calls xcb_flush() from QOpenGLContext::swapBuffers() via xlib. The assertion is clearly about some kind of parallel access to xcb as in Oleg's case it must have set the queue_len to 0 in the same thread before. It seems that xcb is not prepared for that kind of interaction. The theory that XInitThreads() (see QTBUG-31935) fixes it is apparently wrong. Notably the widgets are not using xlib to communicate with xcb and are thus unaffected by any thread synchronization happening there. That is still the case in Qt 5.3.
I've reopened https://bugs.freedesktop.org/show_bug.cgi?id=44198 as, arguably, this interaction with xcb should be allowed.
Apparently we'll ship our own version of xcb in 5.3. If that happens this bug probably doesn't apply to 5.3 anymore.
Attachments
Issue Links
- relates to
-
QTBUG-31935 Parrallel access to xcb and xlib without call to XInitThreads() causes race conditions on X11
- Closed
- resulted in
-
QTBUG-59747 reconsider or refine the blacklisting of Mesa for threaded rendering
- Closed
For Gerrit Dashboard: QTBUG-38221 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
83218,2 | Disable threaded rendering if Mesa is used | release | qt/qtbase | Status: MERGED | +2 | 0 |