[Xcb] Assert in xcb_io.c:542

[Jamey Sharp]

On Wed, Nov 4, 2009 at 5:29 AM, Graeme Gill <graeme2 at argyllcms.com> wrote:
> Jamey Sharp wrote:
>> When _XReply is called, Xlib knows (by looking at the length field)
>> how much data is in the reply. XCB-based libX11 verifies that the
>> caller doesn't try to read more out of the reply than the server
>> claimed to provide. That's the assertion you're failing here.
>
>        thanks for responding. I suspect this assert is happening in
> response to a call to XRRGetCrtcGamma(display, crtc)) under the
> circumstance that the X server says it implements XRandR V 1.2,
> but the underlying graphics card driver does not.
> I think that what happens is this triggers an X protocol error,
> which I catch though an error handler (XSetErrorHandler()) that set
> a (global) flag and returns 0. The call to XRRGetCrtcGamma() is
> then able to return, and my code can continue by switching to an older
> extension to access the VideoLUTs.
> (The underlying problem was raised a while ago on the Xorg list -
> see <http://lists.freedesktop.org/archives/xorg/2008-July/036797.html>)
>
> Does this scenario sound like it would trigger the assert ?

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.

Keithp, your commit message for those crtc bits said "More testing
seems indicated," which is apparently true. :-) Would you fix this
please?

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

>> Bonus points for also getting a network trace to see what protocol
>> went over the wire there; I like using wireshark for that. A network
>> trace from a successful run (with a non-XCB-based libX11, perhaps)
>> might also help.
>
> Hmm - it seems a bit cryptic to use. While it was easy enough to
> capture remote server traffic, the necessary options to capture a local
> server and client escape me, and Google and the wireshark manual/wiki
> give no hints (ie. How do you capture DISPLAY=:0.0 traffic ?). Setting
> wireshark to capture "local" (127.0.0.1) or "any" devices captured nothing.
> The remote X11 server doesn't support XRandR so it's no help.

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.

Jamey