[Xcb] libxcb/libX11 deadlocking and asserting in multi-threaded use

[Nicholas Allen]

Jamey Sharp wrote:
> On Fri, Mar 19, 2010 at 11:18:53AM +0100, Nicholas Allen wrote:
>   
>> I found this bug report in Launchpad:
>> https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/419501
>>
>> This is the exact same assertion that I am seeing.
>>     
>
> That assertion is a symptom of a fairly broad range of problems. All it
> means is that a response arrived for a request that hasn't been sent
> yet.
>   
Sounds impossible ;-)
> In the case of that bug report and its many duplicates, it sounds to me
> like the application opens an X connection, fork()s, and then accesses
> the connection from both processes. That's never going to work.
>   
We don't fork. Everything is done with threads within one process.
> Maybe I don't understand Launchpad, but the bug seems to have been
> reassigned to "GASP Core" and fixed by a new upstream release. (I'd like
> to know what the fix was, but the Ubuntu maintainer apparently didn't
> record that.)
>
>   
>> Is anyone on this list working on this bug?
>>     
>
> Nobody ever tells us about Ubuntu bugs. Then they complain in the Ubuntu
> bug reports that the bugs aren't fixed. *shrug*
>
>   
>> I am also willing to help fix it if I can (and someone will be willing
>> to put up with my questions as I become familiar with the code).
>>     
>
> I'm sure we'll be taking you up on that offer once we figure out what
> the bug actually is. :-)
>   
I'm very interested to find out myself ;-)
> On Fri, Mar 19, 2010 at 04:17:00PM +0100, Nicholas Allen wrote:
>   
>> I've tried wrapping all calls into XLockDisplay but this made no
>> difference. Also according to the documentation I found on the internet
>> this is only needed to group multiple requests into one composite change
>> and the library should be thread safe without needing to call them (in
>> which case each xlib call is a composite change). The only requirement
>> was that XInitThreads is called. Perhaps this documentation was invalid
>> or out of date? I can't remember the link where I read it.
>>     
>
> Nope, that's supposed to be right. Of course, libX11's thread support
> was kludged in late, and while XListFontsWithInfo is the only function I
> know of with unfixable race conditions, I expect there are more buried
> in there.
>
>   
>> In the real Java implementation though we are calling
>> XLockDisplay/XUnlockDisplay from each thread.
>>     
>
> Huh. What are you protecting against there?
>
> By the way, you can always work around Xlib threading issues by using a
> mutex of your own to ensure that you never call Xlib from more than one
> thread at once. I'm told this was a common strategy even before
> Xlib/XCB.
>   
> I'd be even happier, of course, if you ported your Java implementation
> to use XCB directly. ;-) Clemens Eisserer was working on something like
> that, I believe?
>   
That's something I'd be willing to do. The thing is that we use cairo as
a graphics library and I only found documentation for using cairo with
xlib and not xcb directly. Do you know if it's possible to use cairo
with xcb?

Cheers,

Nick