* [Bug libc/13660] poll wrong revents returned
2012-02-03 19:14 [Bug libc/13660] New: poll wrong revents returned teodori.serge at hotmail dot com
@ 2012-02-03 19:47 ` drepper.fsp at gmail dot com
2012-02-04 0:08 ` bugdal at aerifal dot cx
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: drepper.fsp at gmail dot com @ 2012-02-03 19:47 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/13660] poll wrong revents returned
2012-02-03 19:14 [Bug libc/13660] New: poll wrong revents returned teodori.serge at hotmail dot com
2012-02-03 19:47 ` [Bug libc/13660] " drepper.fsp at gmail dot com
@ 2012-02-04 0:08 ` bugdal at aerifal dot cx
2012-02-09 0:19 ` teodori.serge at hotmail dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: bugdal at aerifal dot cx @ 2012-02-04 0:08 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/13660] poll wrong revents returned
2012-02-03 19:14 [Bug libc/13660] New: poll wrong revents returned teodori.serge at hotmail dot com
2012-02-03 19:47 ` [Bug libc/13660] " drepper.fsp at gmail dot com
2012-02-04 0:08 ` bugdal at aerifal dot cx
@ 2012-02-09 0:19 ` teodori.serge at hotmail dot com
2012-02-09 0:42 ` bugdal at aerifal dot cx
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: teodori.serge at hotmail dot com @ 2012-02-09 0:19 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/13660] poll wrong revents returned
2012-02-03 19:14 [Bug libc/13660] New: poll wrong revents returned teodori.serge at hotmail dot com
` (2 preceding siblings ...)
2012-02-09 0:19 ` teodori.serge at hotmail dot com
@ 2012-02-09 0:42 ` bugdal at aerifal dot cx
2012-02-09 22:42 ` teodori.serge at hotmail dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: bugdal at aerifal dot cx @ 2012-02-09 0:42 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/13660] poll wrong revents returned
2012-02-03 19:14 [Bug libc/13660] New: poll wrong revents returned teodori.serge at hotmail dot com
` (3 preceding siblings ...)
2012-02-09 0:42 ` bugdal at aerifal dot cx
@ 2012-02-09 22:42 ` teodori.serge at hotmail dot com
2012-02-10 1:29 ` bugdal at aerifal dot cx
2014-06-13 14:09 ` fweimer at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: teodori.serge at hotmail dot com @ 2012-02-09 22:42 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/13660] poll wrong revents returned
2012-02-03 19:14 [Bug libc/13660] New: poll wrong revents returned teodori.serge at hotmail dot com
` (4 preceding siblings ...)
2012-02-09 22:42 ` teodori.serge at hotmail dot com
@ 2012-02-10 1:29 ` bugdal at aerifal dot cx
2014-06-13 14:09 ` fweimer at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: bugdal at aerifal dot cx @ 2012-02-10 1:29 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/13660] poll wrong revents returned
2012-02-03 19:14 [Bug libc/13660] New: poll wrong revents returned teodori.serge at hotmail dot com
` (5 preceding siblings ...)
2012-02-10 1:29 ` bugdal at aerifal dot cx
@ 2014-06-13 14:09 ` fweimer at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 14:09 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread