Re: Patch for a bug in server/select.c

[Alexandre Julliard]

Bang Jun-Young  writes:
> Suppose that
>     ret = poll( pollfd, nb_users, diff );
>
> has returned an error bit (either of POLLERR, POLLHUP, or POLLNVAL) 
> set in pollfd[].revents. Those error codes are defined in positive 
> numbers in poll.h, so in this case when
>     poll_users[i]->ops->poll_event( poll_users[i], pollfd[i].revents );
>
> is called, it tries to get an access to an already freed function and 
> causes a segfault.

POLLERR and POLLHUP are legitimate results, and you definitely have to
call the function in that case. POLLNVAL is not supposed to happen,
unless there is a bug in the fd management. Or does NetBSD set
POLLNVAL when the file descriptor is -1?  This wouldn't be correct
according to the Single Unix spec.

Patch for a bug in server/select.c

[Bang Jun-Young]

On Wed, May 16, 2001 at 02:09:39PM -0700, Alexandre Julliard wrote:
> POLLERR and POLLHUP are legitimate results, and you definitely have to
> call the function in that case. POLLNVAL is not supposed to happen,
> unless there is a bug in the fd management. Or does NetBSD set
> POLLNVAL when the file descriptor is -1?  This wouldn't be correct
> according to the Single Unix spec.

According to the manpage, NetBSD implementation of poll(2) is different
from historical one in that a given fd may not cause poll to return with
an error. I'm not sure if this is the case, however.

Anyway, I'm attaching another patch for it.

ChangeLog:
    * server/select.c:
    Workaround for a problem that may cause a segfault on NetBSD 
    when the preceding poll returned pollfd.revents with POLLNVAL set.

Jun-Young