(In reply to comment #0)
> We've (LSB) been seeing a few xts5 test failures on nwere distributions that
> seem to correspond with the change from libxcb-1.2 to libxcb-1.3, specifically
> the changes to xcb_conn.c.
> 
I wonder if the check for POLLIN shouldn't also check for POLLHUP/POLLERR.  select() returns an fd as readable on EOF, whereas poll(2) says POLLIN means "There is data to read."

(In reply to comment #1)
> I wonder if the check for POLLIN [in xcb_conn.c] shouldn't also
> check for POLLHUP/POLLERR. 
> select() returns an fd as readable on EOF, whereas poll(2) says POLLIN means
> "There is data to read."

I'd go further in correcting this code (starting around line 318 in xcb_conn.c).  It looks to me like in the case where there's an event with neither POLLIN nor POLLOUT marked, we want to treat this as an error by default, shut down the connection and return 0.   POLLPRI should be treated as POLLIN, I think?

> --- Comment #1 from Julien Cristau <jcristau@debian.org>  2009-09-09 08:13:29 PST ---
> I wonder if the check for POLLIN shouldn't also check for POLLHUP/POLLERR. 
> select() returns an fd as readable on EOF, whereas poll(2) says POLLIN means
> "There is data to read."
> 
Apparently linux returns POLLIN on a closed socket, so scratch that.
(http://www.greenend.org.uk/rjk/2001/06/poll.html)

Great link. "The lesson for authors of portable code is clear: test for both POLLIN and POLLHUP, and rely on the subsequent read() to tell you whether you reached EOF."  I concur.  Now somebody needs to look at the XCB code paths and make that happen.  I still think that POLLERR and POLLNVAL should cause the connection to be closed.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libxcb/issues/9.