Alexander Volkov <a.vol...@rusbitech.ru> writes: > Otherwise a client may receive data with an unrelated file > descriptor after calling recvmsg() if its input buffer is not > big enough. In libxcb it may lead to a situation when all > received messages fit the buffer while a message related to > the attached fd is not received yet. libxcb can't find the > corresponding message and fails with XCB_CONN_CLOSED_FDPASSING_FAILED > error.
Thanks for looking in to this; it looks like a problem to me as well
because xcb does this:
/* If we have any left-over file descriptors after emptying
* the input buffer, then the server sent some that we weren't
* expecting. Close them and mark the connection as broken;
*/
However, fixing this in the server is harder than it appears...
> + if (oc->output && oc->output->count > 0)
> + (void) FlushClient(client, oc, (char *) NULL, 0);
> +
FlushClient doesn't empty the buffer when the kernel buffers are full,
so while calling it here may reduce the occurrence of the problem, it
won't eliminate it.
One way to fix this would be to have the X server OS layer *also* buffer
fds and ensure that they are presented to Xtrans just before the reply
which uses them. Alternatively, we could fix xcb so that it kept the fds
around for 'a while' instead of discarding them immediately. The latter
approach seems a lot easier to me?
--
-keith
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
