[Xcb] mesa +xcb = assertion death

[Jamey Sharp]

On Wed, 2005-05-04 at 13:55 -0400, Jeremy Kolb wrote:
> Okay, they're on http://people.brandeis.edu/~jkolb
> 
> * glx-mesa-xorg-6.8.2-nvidia-noxcb-glxinfo.dump
> glxinfo on Xorg 6.8.2 running the binary nvidia drivers against normal 
> xlibs.
> 
> * glx-mesa-xorg-6.8.2-nvidia-xcb-glxinfo.dump
> glxinfo on Xorg 6.8.2 running the binary nvidia drivers against Mesa's 
> libGL and XCB-enabled xlibs.
> 
> * glx-mesa-xorg-6.8.99.5-nvidia-xcb-glxgears.dump
> glxgears on Xorg 6.8.99.5 running the binary nvidia drivers against 
> Mesa's libGL and XCB-enabled xlibs.

In these configurations there's a reply that appears to be 19056 bytes
long but has a length field of 4760 bytes.

The really surprising thing is that in the glxgears test with XCB, the
app apparently continues running after receiving that reply, and makes a
number of requests related to window creation; these are apparently
successful except for the MapWindow, which is sent with a bad length and
gets a BadLength error back. Perhaps glxgears ignores SIGABRT?

> * glx-mesa-xorg-6.8.99.5-noxcb-glxinfo.dump
> glxinfo on Xorg 6.8.99.5 running 'vesa' against normal xlibs.

Without the Nvidia bits, there's a different request sent where the
reply claims to be 112 bytes long, but appears to actually be 912 bytes
long. (This same thing showed up in the first trace you posted.)


Presumably Mesa is ignoring the length field of the reply in both cases,
and there's some other length information in the vendor-private bits. (I
imagine you can confirm this by reading the relevant Mesa source.) I
believe you've found a bug in the X.org server-side GLX implementation,
where these replies are not having their length computed correctly. You
should file a bug report.

I declare XCB still correct. :-) It'll be unfortunate if Xlib/XCB
doesn't operate on servers with this bug even though traditional Xlib
does... but I'm not interested in adding some bug work-around for them.

--Jamey