[Xcb] problem with xcb-based Xlib and multithreaded applications

Uli Schlachter psychon at znc.in
Tue Jan 4 06:08:57 PST 2011

Hash: SHA256

Am 04.01.2011 14:38, Francesco Abbate wrote:
>> attached is an ugly (e.g. drawing without getting an Expose) test case. The main
>> thread just does XNextEvent and prints all events while a thread does some
>> drawing via XFillRectangle every second. My libX11 uses xcb:
>> $ ldd /usr/lib/libX11.so | grep xcb
>>        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f5b9b3ac000)
>> However, I don't see any hangs from this. It all seems to work fine. What am I
>> doing wrong that makes this work correctly?
> Well, you example seems to be pertinent. The only objection I can
> think about is that I'm using XPutImage instead of XFillRectangle,
> like you are doing, and I was using XSync with Discard to True.

I just made this use XSync(d, True) and managed to make this hang (it worked for
a moment at first). Don't ask me how I managed to do this, it didn't hang on the
second try.
Then I removed all the "sleep(1);" which makes it freeze almost immediately,
even with Discard=False.

Anyway, here are some backtraces:

(gdb) thread 1
[Switching to thread 1 (Thread 0x7f65d777e700 (LWP 9878))]#0  0x00007f65d702846e
in __pthread_mutex_unlock_usercnt (mutex=0x240a6d8, decr=<value optimized out>)
    at pthread_mutex_unlock.c:52
52	in pthread_mutex_unlock.c
(gdb) bt
#0  0x00007f65d702846e in __pthread_mutex_unlock_usercnt (mutex=0x240a6d8,
decr=<value optimized out>) at pthread_mutex_unlock.c:52
#1  0x00007f65d6aac89c in xcb_poll_for_reply () from /usr/lib/libxcb.so.1
#2  0x00007f65d7288ea7 in process_responses (dpy=0x2409070,
wait_for_first_event=<value optimized out>, current_error=<value optimized out>,
    at ../../src/xcb_io.c:222
#3  0x00007f65d7289941 in _XReadEvents (dpy=0x2409070) at ../../src/xcb_io.c:279
#4  0x00007f65d726fdd8 in XNextEvent (dpy=0x2409070, event=0x7fffbb63d3d0) at
#5  0x0000000000400d7d in main () at t.c:72
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f65d6494710 (LWP 9879))]#0  __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
136	../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: Datei oder
Verzeichnis nicht gefunden.
	in ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S
Current language:  auto
The current source language is "auto; currently asm".
(gdb) bt
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1  0x00007f65d70270e9 in _L_lock_953 () from /lib/libpthread.so.0
#2  0x00007f65d7026f0b in __pthread_mutex_lock (mutex=0x240a500) at
#3  0x00007f65d726ebf3 in _XLockDisplay (dpy=0x2409070) at ../../src/locking.c:458
#4  0x00007f65d725ab12 in XChangeGC (dpy=0x240a500, gc=0x24155a0, valuemask=4,
values=0x7f65d6493e10) at ../../src/ChGC.c:40
#5  0x0000000000400b11 in draw (gc=0x24155a0, color=0) at t.c:21
#6  0x0000000000400bb1 in threadf (unused=0x0) at t.c:31
#7  0x00007f65d70248ba in start_thread (arg=<value optimized out>) at
#8  0x00007f65d6d8c02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9  0x0000000000000000 in ?? ()

(According to strace, thread 2 hangs in futex() while thread 1 is in userspace.
Top says this thread does a busy loop)

Now find someone who has a clue about Xlib and can figure out why this hangs, I
can only speculate.


- -- 
- - Buck, when, exactly, did you lose your mind?
- - Three months ago. I woke up one morning married to a pineapple.
  An ugly pineapple... But I loved her.
Version: GnuPG v1.4.10 (GNU/Linux)


More information about the Xcb mailing list