Closing glxgears window causes xcb_xlib_lock assertion and sound interruption

Bug #91077 reported by Sitsofe Wheeler
4
Affects Status Importance Assigned to Milestone
xcb (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: mesa-utils

Description of the problem:
Closing glxgears using the top right hand X on its window frame prints an xcb_xlib_lock: Assertion in ~/.xsession-errors and rather more worryingly causes blips in sound output of totem-gstreamer and rhythmbox...

Steps to reproduce:
1. Start
gnome-terminal .
2. From the terminal start
totem '/home/sits/Examples/ubuntu Sax.ogg' &
3. From within the terminal start
glxgears .
4. Close glxgears using the X at the top right hand corner of the window.

Expected result:
glxgears to close. No output other than fps to be on the terminal. Background sound to continue to play uninterrupted.

Actual result:
glxgears closes. Following output is printed on the terminal:
XIO: fatal IO error 22 (Invalid argument) on X server ":0.0"
      after 29 requests (29 known processed) with 0 events remaining.
glxgears: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
Sound is interrupted and "blips".

How reproducible is this problem:
The xlib.lock error is reproducible every time. The sound interruption is reproducible three quarters of the time.

Additional information:
The blip doesn't seem to occur when using xine-ui to play the background sound. The blip is slight and may require several attempts to identify depending on the exact background sound being played at the time.

Version information:
Ubuntu Feisty
mesa-utils 6.5.2-3ubuntu1

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

which version of libxcb do you have installed? The latest version (1.0-1.1ubuntu2) has a patch which should fix those assertion bugs (in fact, it only skips the locking test).

Changed in mesa:
status: Unconfirmed → Needs Info
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

libxcb1 1.0-1.1ubuntu1 .

I'm aware of the patch that went in to stop the notification of these types of problem (Bug #90757 ?). However after Feisty is released this lock checking will be re-enabled so I might as well report the problem in core packages now. I don't object to seeing legit warnings before the final release but was does worry me is the sound blips that this causes as I have been thinking that X has been less responsive than in previous versions of Ubuntu...

Changed in mesa:
status: Needs Info → Unconfirmed
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

OK, it looks like assertion is being caused by the legacy NVIDIA GL library:

(gdb) thread apply all bt

Thread 1 (process 5358):
#0 0xb7f30410 in __kernel_vsyscall ()
#1 0xb7d92df0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d94641 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7d8c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4 0xb74ef6f4 in xcb_xlib_lock () from /usr/lib/libxcb-xlib.so.0
#5 0xb7cc0c8c in _XCBLockDisplay (dpy=0x804cb30) at ../../src/xcb_lock.c:20
#6 0xb7ca4241 in XESetCloseDisplay (dpy=0x804c340, extension=1, proc=0)
    at ../../src/InitExt.c:231
#7 0xb7edaa69 in ?? () from /usr/lib/libGL.so.1
#8 0x0804c340 in ?? ()
#9 0x00000001 in ?? ()
#10 0x00000000 in ?? ()

Using
LD_PRELOAD=/usr/lib/nvidia/libGL.so.1.2.xlibmesa glxgears
(thus using the original mesa GL library) makes the assertion part of this problem disappear.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Version information:
nvidia-glx-legacy 1.0.7184+2.6.20.2-9.8

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

this is confirmed by upstream :

02:19 < aaronp> tepsipakki: I reproduced the problem and filed bug 302927.
02:32 < aaronp> tepsipakki: It looks like what's happening is that XPending is calling
                XLockDisplay and then encounters an IO error, which calls exit, and libGL
                calls XESetCloseDisplay as part of its cleanup path.

Changed in linux-restricted-modules-2.6.20:
importance: Undecided → Low
status: Unconfirmed → Confirmed
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

I'm going to assume that 302927 in the NVIDIA bugzilla.

Timo:
Thanks for sending this upstream. I did send an email to nvidia about this on the 11th but never received a reply. It seems your contact was far more effective...

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

The consensus among Nvidia engineers is that this is a bug in xcb :)

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

: )

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

From aaronp:
I believe that this is not a bug in libGL. The library needs to unregister
its extension in its teardown path in case it is unloaded with dlclose(3).
The fact that this can happen from inside libX11 while the lock is held is an
issue that libX11 needs to be able to handle.

Revision history for this message
Jamey Sharp (sharpone) wrote :

We believe this bug is fixed in current upstream libX11 git.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

This problem no longer happens in Gutsy. Resolve fixed?

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Resolving fixed as this problem doesn't occur in Hardy either.

Changed in xcb:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.