[Bug libc/13660] New: poll wrong revents returned

[Bug libc/13660] New: poll wrong revents returned

[teodori.serge at hotmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13660

             Bug #: 13660
           Summary: poll wrong revents returned
           Product: glibc
           Version: 2.14
            Status: NEW
          Severity: critical
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: teodori.serge@hotmail.com
    Classification: Unclassified


Hello,
poll() is not returning the right events. If socket has data to read, POLLIN is
set, but if socket is closed or shutdown it also sets POLLIN? It should
normally be POLLERR POLLHUP or POLLNVAL, at least not POLLIN.

Ex.:

int prc = 0;
struct pollfd pfd;
while(prc != -1){
 pfd.fd = connectedsocket;
 pfd.events = POLLIN;
 prc = poll(&pfd, 1, 1000);
 if(prc == -1){
  perror("poll");
 }else if(prc == 0){
  printf("timeout");
 }else if(prc == 1 && pfd.revents == POLLIN){
  recv(pfd.fd, buff, sizeof(buff), 0);
  printf("data: %s\n", buff);
 }else if(prc == 1 && pfd.revents != POLLIN){
  close(pfd.fd);
  printf("socket closed\n");
  prc = -1;
 }
}

Output:
timeout
timeout
timeout
data: Hello //peer send data
timeout
timeout
timeout
data: // peer closed or shutdown socket -> poll is heating up 100% CPU
data:
data:
data:

This is the case on Ubuntu and on my own linux from scratch (linux-3.2.2 +
glibc-2.14.1 compiled with gcc-4.6.2 and the linux-3.2.2 headers).
I doubt that it could be and build error, because I tried it on i386 and x86
with different.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13660] poll wrong revents returned

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13660

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-02-03 19:46:42 UTC ---
poll is a wrapper around a system call.  If you think something is wrong bring
this up with the kernel folks.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13660] poll wrong revents returned

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13660

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> 2012-02-04 00:08:06 UTC ---
This is not a bug. When a socket is at EOF, read returns without blocking (a
zero-length read). This is basically the definition (from an application
standpoint) of EOF. Per POSIX, POLLIN is returned when "Data other than
high-priority data may be read without blocking." A zero-length EOF read is in
this case "data".

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13660] poll wrong revents returned

[teodori.serge at hotmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13660

--- Comment #3 from Teodori Serge <teodori.serge at hotmail dot com> 2012-02-09 00:18:34 UTC ---
Well right now I'm still polling the sockets but if a peer closes connection or
shuts it down, I get POLLIN (I don't think this is normal), so in this case I
will try a read call, which in fact returns -1 (ERRNO -> invalid file
descriptor). The only thing I don't understand why the POLLERR, POLLNVAL or
POLLHUP events, because they are never filled in revent. If peer uses
shutdown(fd, write), it should fill in POLLHUP, and if peer uses close(fd), it
should fill in POLLERR or POLLNVAL???

Anyway at which point in the kernel are thoses events set, because not only
poll() has this problems I tried select and epoll, to be sure...
Can anyone point me to the right direction, thx :)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13660] poll wrong revents returned

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13660

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> 2012-02-09 00:41:38 UTC ---
If you're getting "invalid file descriptor", that is a bug elsewhere in your
code. It indicates not that the peer has closed the socket, but that YOUR
PROGRAM has closed its end of the socket and it calling read on the file
descriptor after closing it. That has nothing to do with poll or glibc.

When the peer has closed the socket and your end is still open, poll should
return POLLIN|POLLHUP for the fd. This is correct because a call to read will
not block; it will return a zero-length read which means EOF.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13660] poll wrong revents returned

[teodori.serge at hotmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13660

--- Comment #5 from Teodori Serge <teodori.serge at hotmail dot com> 2012-02-09 22:41:29 UTC ---
Ok after testing this on Windows and Solaris, I found that only Linux is
handling this in a different manner. Linux set POLLIN if peer closes
connection, and the next recv() will return zero bytes received. This is also a
good method to intercept a hangup. Well then there is no bug, but Linux should
handle this correctly like Windows and Solaris, because it is called a POSIX
function (whicj means Portable Operating System...)
Anyway where can I find someone from the kernel team? Any idea, perhaps anyone
can correct it? Is there also a forum for the kernel developer?
http://www.kernel.org/ doesn't seem to have one.
And thank you again.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13660] poll wrong revents returned

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13660

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 2012-02-10 01:28:14 UTC ---
The current Linux behavior is completely conformant. Per POSIX:

If fildes refers to a socket, read() shall be equivalent to recv() with no
flags set.
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html)

Upon successful completion, recv() shall return the length of the message in
bytes. If no messages are available to be received and the peer has performed
an orderly shutdown, recv() shall return 0.
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/recv.html)

DESCRIPTION
...
POLLIN
Data other than high-priority data may be read without blocking.
[OB XSR]For STREAMS, this flag is set in revents even if the message is of zero
length. This flag shall be equivalent to POLLRDNORM | POLLRDBAND.
...
POLLHUP
A device has been disconnected, or a pipe or FIFO has been closed by the last
process that had it open for writing. Once set, the hangup state of a FIFO
shall persist until some process opens the FIFO for writing or until all
read-only file descriptors for the FIFO are closed. This event and POLLOUT are
mutually-exclusive; a stream can never be writable if a hangup has occurred.
However, this event and POLLIN, POLLRDNORM, POLLRDBAND, or POLLPRI are not
mutually-exclusive. This flag is only valid in the revents bitmask; it shall be
ignored in the events member.
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html)

[end citations]

Note that if sockets are implemented as STREAMS (the traditional sysv way),
POSIX *REQUIRES* poll to set the POLLIN flag when the socket is at EOF (see
above). If not, it makes no explicit requirement, but the fact that data
(zero-length) can be read without blocking implies that POLLIN should be set.
Moreover, the subsequent text for POLLHUP makes it clear that POLLIN and
POLLHUP are not mutually exclusive; both can (and probably should) be set when
the socket is at EOF, although POSIX does not seem to place any requirements
about POLLHUP for sockets. The entire text is in regards to "devices", pipes,
and FIFOs.

Please do not waste the kernel developers' time with your invalid bug report.
Plenty of applications depend on the correct behavior and nobody is going to
change it to meet your incorrect expectations. Just fix your application so
that it accepts both POLLIN and POLLHUP and you'll be able to support both
correct (Linux) and buggy (Windows?) implementations.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13660] poll wrong revents returned

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13660

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.