[Xcb] mesa +xcb = assertion death

[Jamey Sharp]

On Fri, 2005-04-29 at 04:44 -0400, Jeremy Kolb wrote:
> 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.

(For those less familiar with the code base, I'll mention that of
course, '0 & x == 0'. But yes, immediately after the line you quoted
we'll add 0x10000 to it in this case.)

Right. Wow. I suppose there's *some* way that could be my fault, but I'm
having trouble imagining how.

It sounds like you can very reliably reproduce this bug. Would you
capture a protocol trace using either 'xscope -v4' or some network
sniffer like Ethereal, and post a URL for it? I want to see if your X
server is really sending you a busted sequence number stream. Perhaps
XCB is getting misaligned somewhere (but I still can't imagine how).

> 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.

Response type 5 is a ButtonRelease event. (0 is an error, 1 is a reply,
and everything else is an event; you can look up core events in
xproto.xml, xproto.h, or your friendly neighborhood X protocol
reference.)

> Maybe Jamey has an answer?

Not yet, but you're still doing a great job of troubleshooting.

One cool effect of this problem is that it's forcing me to write down a
lot of what I know about debugging these sorts of problems. :-) On the
other hand, it's a little disheartening to realize that I haven't found
many tricks that actually help. :-/

--Jamey