[Xcb] mesa +xcb = assertion death

[Jeremy Kolb]

Jamey Sharp wrote:
> On Wed, 2005-05-04 at 17:52 -0400, Jeremy Kolb wrote:
> 
> I'm just taking a moment to study glxext.c, which looks to me like the
> code on the client side that's making both of the wacky requests, in
> AllocAndFetchScreenConfigs. First thing I noticed is a double-unlock bug
> in the case that a screen doesn't support GL rendering. I also suspect
> that most of the error-handling code leaves the X protocol stream
> unsynchronized, so that later chatter with the server would lose if
> anything goes wrong in this function. (Needs some calls to _XEatData.)
> 

Where/what is that exactly?  Does it make a difference?

> It looks like the three kinds of requests supported by this function
> (GLXVendorPrivateWithReply/GetFBConfigsSGIX, GLXGetFBConfigs, and
> GLXGetVisualConfigs) all reply with a numProps and a numVisuals field,
> and the number of words returned is something like numProps times
> numVisuals (times 2, when not using GLXGetVisualConfigs). The length
> field of the reply is never consulted. So that much of my hypothesis is
> confirmed, at least.
> 

In the docs the reply length is numProps*numVisuals*2 so you are 
correct.  I'm a bit confused about checking the length field as it bombs 
within _XReply() in this case with the assertion error so it never 
reaches past that point.

> Poor design. Ick. They should have just returned numVisuals, and let
> numProps be implied.
> 
> --Jamey
>