[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