[Xcb] mesa +xcb = assertion death

[Jamey Sharp]

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

Would you verify that the debugger reports the same list of fields in
the c->out structure at both of these points? I don't know if ddd tries
to cache debug data or something, so I suppose you might need to use
plain gdb to be certain.

I've had a fair amount of trouble with debugging symbols not matching in
object files compiled at different times, generally caused by trouble
with libtool producing output files named like "libXCB" instead of
"libXCB.so". I haven't figured out why that happened, but running "make
maintainer-clean", then deleting all files mentioned in .cvsignore
files, and finally re-running autogen.sh and recompiling fixed it.
Aieee. A clean checkout would, of course, have similar effects, but
naturally I had uncommitted changes at the time.

And of course (just to nitpick at Bart *grin*) the value 65536 doesn't
contain any 0xff bytes. :-)

--Jamey