[Xcb] mesa +xcb = assertion death
jkolb at brandeis.edu
Wed May 4 19:14:57 PDT 2005
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.
More information about the xcb