[Xcb] mesa +xcb = assertion death

[Jeremy Kolb]

Jamey Sharp wrote:
> 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.)
> 

Jamey I don't see anything here with a reply length of 20 (112 bytes). 
Where is that?

> 
> 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'll check it out.

> 
> 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
> 
> _______________________________________________
> xcb mailing list
> xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb