[Xcb] mesa +xcb = assertion death

Jeremy Kolb jkolb at brandeis.edu
Wed May 4 20:02:28 PDT 2005


Jamey Sharp wrote:
> On Wed, 2005-05-04 at 22:17 -0400, Jeremy Kolb wrote:
> 
>>Jamey Sharp wrote:
>>
>>>In the above-referenced trace, it's the GLX reply for sequence number
>>>12; the length field is 0x70... uh, I guess that's not 112 bytes, but
>>>112 words, which means 448 bytes. Anyway, it's still not covering the
>>>912 byte stream of data.
>>
>>Where are you getting the 912 bytes from? I'm not seeing that in the 
>>log, though the number does look familiar... I seem to recall something 
>>like that when I was tracing through the program.
> 
> 
> I asked Ethereal to "Follow TCP stream", and display in "Hex Dump" mode.
> Then I visually scanned the outgoing bytes to find this particular
> request, and looked at the block of reply bytes immediately after it.
> Finally I subtracted byte offsets (as reported by Ethereal) to find out
> how long that block was.
> 
> It occurs to me that I probably under-counted both replies by 16 bytes
> or so, by not counting the last line of the hex dump.
> 
> I note that numVisuals*numProps*2*4 bytes could have turned out to be
> something like 16 bytes less than the total number of bytes in the
> response. (That's 8 bytes of standard response header, plus 4 bytes for
> each of numVisuals and numProps.) Perhaps you saw 912 computed by Mesa
> inside the screen setup function at some point?

I don't quite remember I might be lying ;)  Isn't the total reply length 
= 32 + 4*length ?

On another note... I looked in the xserver's glx and there was no *2... 
so I added that and checked and it now looks correct wrt 
numProps/numVisuals.  Didn't seem to fix anything though.

Jeremy



More information about the xcb mailing list