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

[Jamey Sharp]

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.

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.

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. :-)

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?

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20100319/bc31946d/attachment.pgp>