lots of trouble with xorg git...

Roland Scheidegger rscheidegger_lists at hispeed.ch
Wed Nov 15 17:50:54 PST 2006

Jamey Sharp wrote:
> On Wed, Nov 15, 2006 at 09:53:38PM +0100, Roland Scheidegger wrote:
>> And last but not least, libX11/xcb issues. Lots of programs just
>> fail an assertion when launched (somewhat similar to these I guess,
>>  https://bugs.freedesktop.org/show_bug.cgi?id=8650, 
>> https://bugs.freedesktop.org/show_bug.cgi?id=8947, but a different
>>  assertion).
> No, I think your troubles are different from the locking bugs we know
> and love. That assertion failure means that Xlib buffered a request
> but, uh, forgot to tell XCB about it.
> Did you configure Xlib with --disable-xthreads? Don't do that. To use
>  XCB, XTHREADS must be defined when building all libraries that use 
> Xlibint.h. This doesn't mean that Xlib actually has to support
> threads, but the LockDisplay and UnlockDisplay macros must expand to
> their normal code. If anybody really wants the ability to disable the
> rest of the thread support, that can be arranged.
Nope. Only used --disable-dmx and --disable-xprint, nothing about xthreads.

> I notice both your examples are Gtk+ apps. Do all Gtk+ apps fail? Do
> any non-Gtk+ apps fail? What version of Gtk+ are you running? I can't
>  reproduce this problem with Mozilla, Firefox, or xscreensaver-demo. 
> (Or anything else, but anyway...)
Yes, looks like only Gtk apps are affected (from that bug), and all of
it (well those which link against libgtk-x11-2.0.so.0, so gtk 2). This 
comes from a suse gtk2-2.8.9 package.

> If the above comments don't help: Would you file a bug report, assign
> it to me, and tell me what OS and architecture you're testing on? If
> you can, please also provide a tcpdump/wireshark packet dump or
> xscope output, along with the values of xcb_req and dpy->request when
> the assertion fails.
I can do that if you want, though I'm not sure it's worth losing any 
sleep over this. It's a too old distro, it doesn't quite seem to work 
too well nowadays, and I'm going to nuke it anyway... Could be some 
buggy/misbuilt gtk libs. In any case, the numbers for xcb_req and 
dpy->request looked quite normal to me, except that xcb_req is always 2 
less than dpy->request (for example 420/422) when such a crash happens.
Oh, and btw it's not true the apps instantly fail. After start, as long 
as they do not get focus (depending on wm), they work - approach them 
with the mouse and they are gone ;-).


More information about the xorg mailing list