I think the correction will help.
I have recompiled tigervnc with the server version from
cgit.freedesktop.org (currently it does not contain the patches yet),
but, as I see, cleanup after client abort is performed much more quickly
than in version used by Debian. From this reason repetition of this
error is much more difficult. I was unable to repeat it.
One notice not related to this error. I'm looking at FlushClient
function in io.c and I see one weird thing. It contains the following "if":
if (trans_conn && (len = _XSERVTransWritev(trans_conn, iov, i))
>= 0) {...
Later there are "else if" constructs with checks of errno variable, but
it makes sense to check errno only when _XSERVTransWritev() was invoked
and returned error. If the trans_conn variable is set to 0, the errno is
0 (it is set before the "if"). In particular when SUSNSYSV is defined,
the second "if" is always true when trans_conn is NULL. I think it was
not the intention.
On 05/18/2017 02:00 AM, Michel Dänzer wrote:
On 18/05/17 12:50 AM, Rafal wrote:
No, this is not the case. The problem more subtle. Client connection
is closed but the entry is not marked as deleted in ospoll, so any
cleanup of deleted entries will not help. The problem is that entries
in ospoll are searched by fd (file descriptor). These descriptors are
unique for all open files, but the descriptor may be reused when some
file is closed (and usually it is reused).
New patch series related to this:
https://patchwork.freedesktop.org/patch/156892/
https://patchwork.freedesktop.org/patch/156893/
https://patchwork.freedesktop.org/patch/156894/
https://patchwork.freedesktop.org/patch/156891/
https://patchwork.freedesktop.org/patch/156895/
