[Xcb] mesa +xcb = assertion death

[Jeremy Kolb]

Okay.

In line 250 of xcb_in_read_packet we have:

c->in.request_read = (lastread & 0xffff0000) | genrep.sequence;

For some reason when it fails genrep has a response_type of 5, a 
sequence of 0 and a length of 1.  This is when it should be pixing up 
sequence 12 I believe.  Up until this point I get perfectly sane values 
for this.

I don't know why it's getting this value for genrep.  But it causes the 
next read to be 65536 since 0 & 0xffff = 65536.  And that's why the 
assertion fires.

However I have no idea why the generic reply is returning 0 as a 
sequence number, nor do I know what response_type 5 is.

Maybe Jamey has an answer?

Jeremy


Jamey Sharp wrote:
> On Thu, 2005-04-28 at 17:27 -0400, Jeremy Kolb wrote:
> 
>>Okay, the error is in getting the reply for GLXGetFBConfigs (and 
>>GLXGetFBConfigsSGI which is just an alias for the former) in 
>>AllocAndFetchScreenConfigs.  From there it goes:
>>_XReply -> XCBWaitForReply -> _xcb_conn_wait
>>
>>The problem occurs in _xcb_conn_wait at:
>>
>>if ((ret = _xcb_read_int(c) >= 0)
>>
>>then in xcb_in_read_packet in _xcb_read_int().  This is were it gets 
>>confusing.  When xcb_in_read_packet returns the value of 
>>c->in.request_read suddenly becomes 65536 on my computer but I couldn't 
>>find where it was set to that... it simply became that when the function 
>>returned (using ddd with gdb as the debugger).