[Xcb] mesa +xcb = assertion death

[Jeremy Kolb]

Jeremy Kolb wrote:
> Jamey Sharp wrote:
> 
>> On Wed, 2005-05-04 at 00:11 -0400, Jeremy Kolb wrote:
>>
>>> Okay, I've been trying to narrow it down so I recompiled vanilla cvs 
>>> Mesa against the standard non xcb-ified xlibs.
>>>
>>> 1) glxgears using Xorg 6.8.2 and NVidia drivers: no problem.
>>> 2) glxgears using Xorg 6.8.2 libs and Mesa: no problem.
>>> 3) glxgears using xlibs from cvs with XCB enabled: error.
>>> 4) glxgears using xlibs from cvs with XCB enabled and Mesa: error.
>>> 5) glxgears using xlibs from cvs with XCB enabled and NVidia drivers: 
>>> error.
>>>
>>> This is with Mesa compiled against Xorg 6.8.2 xlibs in 
>>> /usr/X11R6/lib. My xlibs --with-xcb is in /opt/fdo/lib.  And 'using' 
>>> above means modifying LD_LIBRARY_PATH to point to /opt/fdo/lib or 
>>> nothing at all.  I used ldd `which glxgears` after each 
>>> LD_LIBRARY_PATH change to verify. The assertion failure only seems to 
>>> happen while using X11 with XCB support enabled :(
>>
>>
>>
>> It seems pretty clear that something odd is happening on the wire when
>> the assertion failure triggers, though.
>>
>> Would you capture tcpdump, Ethereal, whatever traces of at least cases 1
>> and 2 above?
>>
>> Can you also perhaps find out for me what this GLX request means?
>>
>> 9e 11 04 00  04 00 01 00  03 00 00 00  00 00 00 00
>>
>> Major opcode 9e was GLX on your server at the time of this request;
>> minor opcode 0x11 is VendorPrivateWithReply. You were using a
>> little-endian client. What is vendor_code 0x10004? (And does that
>> request really use a LISTofBYTE without an explicit list length field,
>> like it looks as though your GLX XML description says?)
>>
>> --Jamey
>>
> 
> The docs say that yes it is a LISTofBYTE.  This isn't using XCB's GLX 
> though, it's all from xlibs and mesa.  XCB's GLX shouldn't have anything 
> to do with it.
> 
> 0x10004 is for GLXGetFBConfigsSGIX which is the request that they are 
> sending.  The next byte 0x0 is for the screen.  In Mesa 
> GLXGetFBConfigsSGIX is just an alias for the standard GLXGetFBConfigs. I 
> actually tried to force it to use the normal GLXGetFBConfigs but I still 
> got the same result.
> 
> Jeremy


I had written a reply to this only to have it destroyed when glxinfo 
crashed my xserver which I will get to in a little bit.

So here's what we have for dissecting that request:

typedef struct {
     CARD8 major_opcode;			// 0x9e	(158)
     CARD8 minor_opcode;			// 0x11 (17)
     CARD16 length;			// 0x04
     CARD32 vendor_code;			// 0x10004 (GetFBConfigsSGIX)
} XCBGlxVendorPrivateWithReplyReq;

Okay, there is also a list of bytes to follow, the length of which is 
2+(m+p)/4.  So m+p=8, m = size of the list, p = size of padding.  The 
list of bytes is a 4 byte int of the screen number 0x00000003 (this is 
just an alias of GetFBConfigs) so there there should be 4 bytes of 
padding... I see 5 for some reason but I'm just assuming that's random 
server padding to make the whole thing 16 bytes?

Okay on to the crash I just received.  Now, with Mesa compiled against 
the xorg 6.8.2 xlibs and LD_LIBRARY_PATH equals mesalibs:xlibs-with-xcb 
when running glxgears with the NVIDIA drivers I now get:

X Error of failed request:  BadLength (poly request too large or 
internal Xlib length error)
   Major opcode of failed request:  33 (X_GrabKey)
   Serial number of failed request:  19
   Current serial number in output stream:  19

When running glxinfo however it crashes my x server, however if I just 
set the path to either one or the other but not both it works fine.

Jeremy