Bug 14333 - Threads stuck below _XReply
Summary: Threads stuck below _XReply
Status: RESOLVED FIXED
Alias: None
Product: XCB
Classification: Unclassified
Component: Library (show other bugs)
Version: 1.1
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Jamey Sharp
QA Contact: xcb mailing list dummy
URL:
Whiteboard:
Keywords: have-backtrace
Depends on:
Blocks:
 
Reported: 2008-02-01 18:45 UTC by Darren Salt
Modified: 2009-10-12 07:22 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Backtrace and brief description (8.32 KB, text/plain)
2008-02-01 18:45 UTC, Darren Salt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Darren Salt 2008-02-01 18:45:38 UTC
Created attachment 14087 [details]
Backtrace and brief description

With gxine (current dev) built with --with-xcb, I find that xine-lib-1.2's xxmc plugin (which is still X11-based) appears to be triggering a hang. In the attached backtrace, three threads are stuck below _XReply.

I'm using mostly Debian testing/unstable, but libx11-6 is taken from experimental.
(Details in the backtrace file.)

It's possible that this is a gxine problem or a library mismatch; if so, I'd like to know (but I'm reasonably sure that this deadlock shouldn't be happening, even so).
Comment 1 Josh Triplett 2008-03-15 22:17:41 UTC
Jamey and I just announced a set of changes to XCB and Xlib/XCB which, among other things, should address all the outstanding synchronization problems that we know of.  Could anyone experiencing this bug please build XCB and Xlib with the patches found at http://lists.freedesktop.org/archives/xcb/2008-March/003347.html and retest?
Comment 2 Kevin James 2009-10-07 17:20:58 UTC
I've just tried to apply the patches mentioned in comment #1, against the tarball in the source package for openSuSE 11.0 (xorg-x11-libxcb-7.3-48.1.src.rpm, tarball is libxcb-1.1.tar.bz2 - however, the first patch fails. Are these patches already included? I'm seeing this issue with a program called xvidcap, where after a while the deadlock is reached and the program hangs. The backtrace is:

desktop:~/tmp/xvidcap-1.1.7> gdb --directory=src xvidcap
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...
(gdb) run
Starting program: /home/kjames/bin/xvidcap 
[Thread debugging using libthread_db enabled]
[New Thread 0x7ff0a3e726f0 (LWP 28456)]
[New Thread 0x423cd950 (LWP 28459)]
[mjpeg @ 0x83ba00]removing common factors from framerate
[New Thread 0x41715950 (LWP 28460)]
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7ff0a3e726f0 (LWP 28456)]
0x00007ff0a0792dd9 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007ff0a0792dd9 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
#1  0x00007ff0a012684d in _XDisplayLockWait (dpy=0xc5ec00) at
locking.c:468
#2  0x00007ff0a0140e45 in _XCBLockDisplay (dpy=0xc5ec00) at
xcb_lock.c:19
#3  0x00007ff0a0141b62 in _XReply (dpy=0xc5ec00, rep=0x7fffabeae4a0,
extra=2, discard=0) at xcb_io.c:367
#4  0x00007ff0a018e678 in _XkbHandleGetMapReply (dpy=0xc3e844,
xkb=0xd97da0) at XKBGetMap.c:521
#5  0x00007ff0a018f0fb in XkbGetUpdatedMap (dpy=0xc5ec00, which=7,
xkb=0xd97da0) at XKBGetMap.c:543
#6  0x00007ff0a018f1f6 in XkbGetMap (dpy=0xc5ec00, which=7,
deviceSpec=256) at XKBGetMap.c:561
#7  0x00007ff0a018abf9 in _XkbLoadDpy (dpy=0xc5ec00) at XKBBind.c:507
#8  0x00007ff0a018c0d5 in XRefreshKeyboardMapping (event=0x7fffabeae900)
at XKBBind.c:397
#9  0x00007ff0a2efa9e5 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#10 0x00007ff0a2efbe57 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#11 0x00007ff0a2efc27e in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#12 0x00007ff0a16b595a in g_main_context_dispatch ()
from /usr/lib64/libglib-2.0.so.0
#13 0x00007ff0a16b9060 in ?? () from /usr/lib64/libglib-2.0.so.0
#14 0x00007ff0a16b952d in g_main_loop_run ()
from /usr/lib64/libglib-2.0.so.0
#15 0x00007ff0a35f9977 in gtk_main ()
from /usr/lib64/libgtk-x11-2.0.so.0
#16 0x000000000042e5d9 in xvc_ui_run () at gnome_ui.c:2052
#17 0x0000000000439ac2 in main (argc=<value optimized out>,
argv=0x7fffabeaed68) at main.c:992
(gdb) t 2
[Switching to thread 2 (Thread 0x423cd950 (LWP 28459))]#0
0x00007ff0a0792dd9 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007ff0a0792dd9 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
#1  0x00007ff0a0141766 in process_responses (dpy=0xc5ec00,
wait_for_first_event=0, 
    current_error=0x423ccee8, current_request=88742) at xcb_io.c:75
#2  0x00007ff0a0141b7a in _XReply (dpy=0xc5ec00, rep=0x423ccf40,
extra=0, discard=0) at xcb_io.c:370
#3  0x00007ff09fcd3e9b in XShmGetImage () from /usr/lib64/libXext.so.6
#4  0x00000000004279c7 in captureFrameToImageSHM (dpy=0xc5ec00,
image=0xd991c0) at capture.c:957
#5  0x0000000000428a12 in commonCapture (capfunc=SHM) at capture.c:1547
#6  0x000000000042e89d in do_record_thread () at gnome_ui.c:663
#7  0x00007ff0a078f040 in start_thread () from /lib64/libpthread.so.0
#8  0x00007ff0a050208d in clone () from /lib64/libc.so.6
#9  0x0000000000000000 in ?? ()
(gdb) t 3
[Switching to thread 3 (Thread 0x41715950 (LWP 28460))]#0
0x00007ff0a04fb622 in select ()
   from /lib64/libc.so.6
(gdb) bt
#0  0x00007ff0a04fb622 in select () from /lib64/libc.so.6
#1  0x0000000000441b36 in audio_read_packet (s1=<value optimized out>,
pkt=0xf99898)
    at libavdevice/audio.c:259
#2  0x0000000000448795 in av_read_frame_internal (s=0xf98950,
pkt=0x417150a0) at libavformat/utils.c:501
#3  0x000000000043dee2 in capture_audio_thread (job=0xdf3020) at
xtoffmpeg.c:838
#4  0x00007ff0a078f040 in start_thread () from /lib64/libpthread.so.0
#5  0x00007ff0a050208d in clone () from /lib64/libc.so.6
#6  0x0000000000000000 in ?? ()
(gdb) 
Comment 3 Jamey Sharp 2009-10-07 17:44:58 UTC
(In reply to comment #2)
> I've just tried to apply the patches mentioned in comment #1, against the
> tarball in the source package for openSuSE 11.0
> (xorg-x11-libxcb-7.3-48.1.src.rpm, tarball is libxcb-1.1.tar.bz2 - however, the
> first patch fails. Are these patches already included? I'm seeing this issue
> with a program called xvidcap, where after a while the deadlock is reached and
> the program hangs.

Socket handoff was first released in libxcb 1.1.92 and libX11 1.1.99.2, so no, you don't have the bits that should fix the bug you're seeing. Would you re-test with a more recent libxcb and libX11, and see if the bug goes away?

While we're looking at this bug, Darren, can you comment on whether the xine bug you saw is fixed? Debian unstable has had socket-handoff for close to a year now, and it'd be nice to close this bug.
Comment 4 Darren Salt 2009-10-09 05:53:22 UTC
Seems fine here; I've not seen this problem occurring for some time now.
Comment 5 Jamey Sharp 2009-10-09 07:29:43 UTC
(In reply to comment #4)
> Seems fine here; I've not seen this problem occurring for some time now.

Thanks Darren. In that case, I'm closing this bug as fixed with socket-handoff.

Kevin, if you can reproduce your problem on newer libxcb/libX11, please file a new bug with the details. I'm not even remotely excited about trying to fix this problem in the old codebase, but if a distro stable release manager needs a solution in old libX11 we could discuss options on the xcb mailing list.
Comment 6 Kevin James 2009-10-09 07:33:22 UTC
I spoke to the openSuSE maintainer and he said that in 11.2 they will be using newer versions, so I'm just getting 11.2 Milestone 8 installed to verify this is fixed. I will update here when I know more
Comment 7 Kevin James 2009-10-12 07:22:36 UTC
Just tested this on openSuSE 11.2 Milestone 8, which uses the newer libxcb/libX11, and appears to be working fine. Bug can stay resolved-fixed for me.


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.