[Xcb] Number of iovecs for xcb_send_request()

[Peter Harris]

On Sun, Aug 12, 2012 at 9:17 AM, Uli Schlachter wrote:
>
> recently I stumbled upon a PDF which evince could not display. It would always
> die with an XIO error. Through some debugging, I noticed that this was due to
> some magic that cairo does to avoid having to copy data around:
>
> http://cgit.freedesktop.org/cairo/tree/src/cairo-xcb-connection-core.c#n162
>
> I wrote a test case for cairo which reproduces this problem. However, for this
> report, I also wrote an xcb-only test case. See the attached program.
>
> The problem is that xcb tries to write out the huge number of struct iovs in a
> single call to writev(). However, there is an upper limit on the number of
> iovs that are accepted. This limit causes writev() to fail with EINVAL.
>
> So my question now is: Where is the bug? If cairo is doing something wrong, it
> would have to split the PutImage up into multiple individual requests. I'd
> like to avoid this, if possible (And in this case, someone should extend xcb's
> documentation to explain this limit and how it should be handled).

Yeah, that is awkward. I'm not sure exactly where to place this bug
(xcb, or xcb's documentation), but that use case is compelling enough
that xcb ought to be extended to handle it (ie. I think it's a bug in
xcb even if it isn't a bug in xcb[1]).

> If this
> problem should be handled in xcb, then... I'm not really sure how this should
> be handled.

Something like the attached (untested) patch to libxcb ought to help.

Peter Harris

[1] Does that even make sense? Hopefully I'm allowed to be nonsensical
on the weekend. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-xcb_send_request-with-IOV_MAX-iovecs.patch
Type: application/octet-stream
Size: 1017 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20120812/82d51b5f/attachment.obj>