[Xcb] Looking for ways to find a threading issue

[Clemens Eisserer]

Hi Uli,

Thanks for your response.

> XCB is always perfectly thread-safe as soon as it is linked with libpthread, so
> this is unlikely to be an issue with XCB at all. However, there could be a
> problem if you call into XCB from another thread while

I would never dare to claim it is xcb's fault ;)


> Also, I wonder why you can't just call XInitThreads(), but I doubt that I want
> to know the answer to this.

Most likely performance. OpenJDK locks it's own data-structures
anyway, so there is no point in double-locking.
pthread-mutexes are expensive ; )


> The only thing that I can think of right now: Call XInitThreads() and see if
> that fixes the issue. Just to be sure that you are really on the right track.
> But I guess you already did that.

Nope, hadn't done it before.
And it also didn't help, which seems to confirm it isn't a threading issue :/


> It's always this message? From a quick look at libX11, this happens if libX11
> receives an event with a sequence number that is larger than the last sent
> sequence number.
>
> In other words, we have only sent 10 requests to the server, but there is an
> event which was generated after request 15 was handled by the server.

No, most of the time (it is perfectly reproduceable) it gets stuck
waiting for a reply with a callstack like this:

#0  0x00007fbe82f5efbd in poll () at ../sysdeps/unix/syscall-templa
te.S:81
#1  0x00007fbe540bd982 in poll (__timeout=-1, __nfds=1,
__fds=0x7fbe8364c4e0) at /usr/include/x86_64-linux-gnu/
bits/poll2.h:46
#2  _xcb_conn_wait (c=c at entry=0x7fbe7c1eba80,
cond=cond at entry=0x7fbe8364c550, vector=vector at entry=0x0,
count=count at entry=0x0) at ../../src/xcb_conn.c:400
#3  0x00007fbe540bee57 in wait_for_reply (c=c at entry=0x7fbe7c1eba80,
request=14400, e=e at entry=0x7fbe8364c608) at ../../src/xcb_in.c:395
#4  0x00007fbe540bf07b in xcb_wait_for_reply (c=0x7fbe7c1eba80,
request=14400, e=0x7fbe8364c608) at ../../src/xcb_in.c:425
#5  0x00007fbe549352d9 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fbe54930d5d in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007fbe54e78e30 in Java_sun_awt_X11_XRobotPeer_keyReleaseImpl
() from /export/prj/jdk8/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/jre/lib/amd64/libawt_xawt.so

For me this issue is quite confusing.
It seems the whole behaviour is triggered by a calls to XRenderCompositeText32.
In case I call XRenderFillRectangle or even XRenderCompositeText16
instead, the test-case works as expected without any hiccups.


Regards, Clemens