X server bug on BIG-REQUESTS?

[Jamey Sharp]

Orhun Birsoy wrote:
> I am having problems when I resize my window greater than a certain 
> size. XCBPollForEvent returns NULL and error parameter is -1. I copy an 
> image(XCBImage) to a window using XCBImagePut. But everything seems to 
> work if use to copy the image in parts instead of in one call using 
> XCBPutImage (not XCBImagePut).

I've finally tried compiling and running your program :-) and it fails
for me the same as for you. I've written a much simpler test case that
also demonstrates the problem: it's attached.

I wrote:
> [In XCB,] sequence 0 means "we couldn't send your request to the
> server", but doesn't tell you more than that. However there are only
> three ways it can fail:
> 
>  - If the request is not part of the core protocol but rather comes
>    from an extension, and the server does not support the extension.
>  - If the length of the request is greater than the maximum request
>    length from the connection setup reply (max 256kB) or from the
>    BIG-REQUESTS 'Enable' reply (max 16GB) if that's supported.
>  - If the 'select' or 'writev' system calls fail. I don't think this
>    can happen in practice unless the connection closes.

We know XCBPutImage can't trigger #1, and I've now established that it
isn't failing at #2 (request too big even for BIG-REQUESTS) but at #3
(I/O error). I did this with basic gdb-based troubleshooting. XCB gets
the request header written, but writev returns without writing the image
data. XCB again selects on the socket for reading and writing, gets that
the socket is ready for reading, tries to read, and gets an I/O error.
The remaining write is abandoned.

I also used Ethereal to watch the exchanges between the app and the X
server, but Ethereal failed to capture most of the packets, so all I
could tell was that connection-close was initiated by the X server. This
is interesting information though.

Orhun Birsoy wrote:
> XCBGetMaximumRequestLength returns 4194303. Strangely enough this
> number is very close to my image size that causes problems but
> according to the documentation this should be a number representing
> 16777212 bytes (which is also confirmed by xdpyinfo, see below).

On my system, my test app reports the following:

	maximum request length in 4-byte units: 4194303
	creating a 1024x1024 pixmap (1048576 pixels, 4194304 bytes)
	create.sequence = 3; put.sequence = 0
	XCBFlush failed.
	XCBPollForEvent: I/O error occured, but no handler provided.
	Aborted

At this point I believe we've identified an X server bug, and I think
the error is in the ReadRequestFromClient function in os/io.c, but this
function is incomprehensible to me. I think the symptom is that this
function is incorrectly returning -1 (causing a call to CloseDownClient
in Dispatch) when we send it this large request. It's worth noting the
comment that says, "Watch out: needed sometimes counts bytes and
sometimes counts CARD32's," which sounds like exactly the kind of
confusion we're seeing.

Standard advice for a long time has been to not send really large
requests to the X server anyway, on the grounds that they can block the
server from processing requests from other clients for a while. If this
is a server bug, it's conceivable that simply no Xlib application ever
generates a 4MB request, so nobody ever saw this problem before.

Anyway, at this point I'd appreciate comments from folks more familiar
with the DIX layer than I am.

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: big-crash.c
Type: text/x-csrc
Size: 1629 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060609/129ca206/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060609/129ca206/attachment.pgp>