When converting Xlib/XCB to use only XCB's public API, I assumed that Xlib protocol stubs don't ever call the Data family of macros more than once per GetReq. I thought doing so would be a bug because Data can call _XFlush and I thought that might lead to a race in multi-threaded settings. It looks like it doesn't lead to a race, though, and XStoreColors (for one) does call Data many times. This causes an assertion failure in current Xlib/XCB if XStoreColors is called with more colors than will fit in Xlib's 16kB output queue. (!) I need to properly handle multiple calls to Data in Xlib/XCB.
I believe I have this fixed in my local GIT repo. I'm waiting for confirmation that there was ever a bug to begin with before I push the patch, so I can check that the patch worked.
My committed fix repaired the immediate issue but exposed a new one. The X Test Suite test purpose that illustrates both bugs is in Xlib7, XCreateColormap purpose 6. The new failure mode is an assert failure in _XUnlockDisplay.
XRenderCompositeText8 also calls Data multiple times, and I've hit this using gconf-editor and clicking apps->evolution->general (boom). With the latest bits, I instead hit: Assertion failed: (XCBGetRequestSent(dpy->xcl->connection) == dpy->request), function _XUnlockDisplay, file xcl/xcblock.c, line 49.
Created attachment 5585 [details] test case that triggers these bugs using XStoreColors. storecolors: xcl/xcblock.c:49: _XUnlockDisplay: Assertion `XCBGetRequestSent(dpy->xcl->connection) == dpy->request' failed. XCBGetRequestSent(dpy->xcl->connection) is 7; dpy->request is 6.
I believe this is finally completely fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.