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/