[Xcb] Assert in xcb_io.c:542

[Graeme Gill]

Jamey Sharp wrote:
> I was thinking "no, that's crazy" ;-) but it looks to me like
> XRRGetCrtcGamma is really buggy in its handling of X errors. If the
> response is an X error, all the code does is set a flag that it then
> ignores; it reads the resource ID field of the error as "length", and
> the minor opcode as "size", and tries to read more list contents. That
> last would definitely trigger this assert.

OK, so there is an explanation for the assert. It turns out that
my guess at the particular trigger was incorrect, although I would expect
it is still an X error that gets generated and causes the assert.

Apparently what happens is the user hotplugs a new display but doesn't
configure it:

1. Start with only laptop panel connected.  dispwin works.
2. Plug in VGA cable.  dispwin fails.
3. xrandr --output VGA1 --right-of LVDS1 --auto.  dispwin works again.

(I'm not clear on what is exactly meant by "dispwin fails", although I
suspect it means the xcb assert gets triggered.)

I'm also not clear on whether the above is expected XRandR behavior
or not (my Intel display is built into the motherboard and doesn't
allow for an external display, so I don't think I can test it myself.)

> Graeme, I'm obligated to point out that if you use XCB for this
> request (see http://xcb.freedesktop.org/MixingCalls/) then you get a
> substantially better error-handling interface, as well as avoiding
> Keith's buggy code. ;-) You could throw away your global flag and
> error-handling callback. That would tie you to versions of Xlib built
> on XCB, but I have trouble being sad about that. ;-)

A better error handler is welcome, but I'm not sure If I'm going
to re-write using xcb just yet though, sorry :-)

> If you set DISPLAY=localhost:0 then the client will use TCP on the
> loopback interface and wireshark can capture that. Of course your X
> server can't be running with "-nolisten tcp", which is default in many
> installations. I wish wireshark could capture from Unix domain
> sockets... Anyway, we probably don't need a network trace after all.

OK, thanks to your hint I got it working to the localhost and got a capture
of normally working situation. Is it worth asking the user who reported
the problem to do the same ?

cheers,
	Graeme Gill.