[Xcb] Assert in xcb_io.c:542

[Graeme Gill]

Jamey Sharp wrote:
> On Tue, Nov 3, 2009 at 9:08 PM, Graeme Gill <graeme2 at argyllcms.com> wrote:
>> % dispcal -v -q l -y l test
>> dispcal: ../../src/xcb_io.c:542: _XRead: Assertion
>> `dpy->xcb->reply_data != ((void *)0)' failed.
>> zsh: abort (core dumped)  dispcal -v -q l -y l test
> 
> This is an assert in Xlib, and is another case of new libX11 checking
> for caller errors that old libX11 didn't explicitly check.
> 
> 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.

Hi,
	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 ?

> As far as I know, old libX11 should have started producing wrong
> answers after that point, unless the buggy client code was matched by
> buggy server code, or the client exits immediately after getting that
> reply.

> The first important thing to do, if that description didn't already
> point you in the right direction, is to get a stack trace, with
> debugging symbols for libX11 and for whatever code is calling it when
> the assertion fires.

Not easy, since I'm not in a position to reproduce it, and the user
who reported doesn't seem to be hugely technical.

> 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 there turns out to be an X server bug here, it'd also be good to
> know what server version is running, such as from xdpyinfo.

> name of display:    :0.0
> version number:    11.0
> vendor string:    The X.Org Foundation
> vendor release number:    10604000
> X.Org version: 1.6.4
> maximum request size:  16777212 bytes
> motion buffer size:  256
> bitmap unit, bit order, padding:    32, LSBFirst, 32
> image byte order:    LSBFirst
> number of supported pixmap formats:    7
> supported pixmap formats:
>     depth 1, bits_per_pixel 1, scanline_pad 32
>     depth 4, bits_per_pixel 8, scanline_pad 32
>     depth 8, bits_per_pixel 8, scanline_pad 32
>     depth 15, bits_per_pixel 16, scanline_pad 32
>     depth 16, bits_per_pixel 16, scanline_pad 32
>     depth 24, bits_per_pixel 32, scanline_pad 32
>     depth 32, bits_per_pixel 32, scanline_pad 32
> keycode range:    minimum 8, maximum 255
> focus:  window 0x2e00095, revert to PointerRoot
> number of extensions:    27
>     BIG-REQUESTS
>     Composite
>     DAMAGE
>     DOUBLE-BUFFER
>     DPMS
>     DRI2
>     GLX
>     Generic Event Extension
>     MIT-SCREEN-SAVER
>     MIT-SHM
>     RANDR
>     RECORD
>     RENDER
>     SECURITY
>     SGI-GLX
>     SHAPE
>     SYNC
>     X-Resource
>     XC-MISC
>     XFIXES
>     XFree86-DGA
>     XFree86-VidModeExtension
>     XINERAMA
>     XInputExtension
>     XKEYBOARD
>     XTEST
>     XVideo
> default screen number:    0
> number of screens:    1
> 
> screen #0:
>   dimensions:    1440x900 pixels (381x238 millimeters)
>   resolution:    96x96 dots per inch
>   depths (7):    24, 1, 4, 8, 15, 16, 32
>   root window id:    0x119
>   depth of root window:    24 planes
>   number of colormaps:    minimum 1, maximum 1
>   default colormap:    0x20
>   default number of colormap cells:    256
>   preallocated pixels:    black 0, white 16777215
>   options:    backing-store NO, save-unders NO
>   largest cursor:    64x64
>   current input event mask:    0x7a803f
>     KeyPressMask             KeyReleaseMask           ButtonPressMask          
>     ButtonReleaseMask        EnterWindowMask          LeaveWindowMask          
>     ExposureMask             StructureNotifyMask      SubstructureNotifyMask   
>     SubstructureRedirectMask FocusChangeMask          PropertyChangeMask       
>   number of visuals:    72
>   default visual id:  0x21

Graeme Gill.