Bug #100807 for IO-Async: IO::Async::Loop::Poll doesn't check POLLNVAL, 100% CPU if it happens

Tue Dec 09 13:51:43 2014 chadd [...] fidelissys.com - Ticket created

Subject:

IO::Async::Loop::Poll doesn't check POLLNVAL, 100% CPU if it happens

IO::Poll handles() always masks in POLLHUP|POLLERR|POLLNVAL, but IO::Async::Loop::Poll does not check for POLLNVAL to trigger errors on those handles. If it happens (which is obviously a bug, but I haven't been able to find it in my code yet), then top shows massive CPU usage for the process. Using strace shows poll(2) immediately returning POLLNVAL for the bad descriptor, but the userland just issues some gettimeofday(2) calls and returns to poll(2) with the same request set, which returns POLLNVAL.... Observed (only under production load) using IO::Async 0.63 and IO 1.31 (IO::Poll 0.09) installed from Ubuntu Utopic repositories, but from metacpan's browser, it looks like 0.64 should also be affected. Using IO::Async::Loop::EV seems to avoid the CPU usage, although it naturally still generates warnings like: EV: error in callback (ignoring): Can't call method "sysread" on an undefined value at /usr/share/perl5/IO/Async/Stream.pm line 909.

Sat Dec 13 10:48:59 2014 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Tue Dec 09 13:51:43 2014, cdael wrote: Show quoted text

> IO::Poll handles() always masks in POLLHUP|POLLERR|POLLNVAL, but > IO::Async::Loop::Poll does not check for POLLNVAL to trigger errors on > those handles. > > If it happens (which is obviously a bug, but I haven't been able to > find it in my code yet),

Are you using HTTPS (or some other SSL protocol) by any chance? There's a bug in the combination of IO::Poll + IO::Socket::SSL which causes this kind of thing. https://rt.cpan.org/Ticket/Display.html?id=93107 The trouble with POLLNVAL is that it's not directly a complaint about the state of a filehandle; it's a complaint about the state of the pollfd array directly in that it contains an actually-invalid filehandle. I don't quite know what the correct behaviour ought to be on this, because simply throwing an error at the Notifier the Loop thinks responsible for it is unlikely to remove it, on account of it not actually existing. See if applying the patch in the above linked ticket fixes the issue; if so I expect it's just the SSL+Poll combination. -- Paul Evans

Sat Dec 13 10:48:59 2014 The RT System itself - Status changed from 'new' to 'open'

Mon Dec 15 08:51:42 2014 chadd [...] fidelissys.com - Correspondence added

From:

chadd [...] fidelissys.com

On Sat Dec 13 10:48:59 2014, PEVANS wrote: Show quoted text

> Are you using HTTPS (or some other SSL protocol) by any chance?

I was. I could have *sworn* I tested it without SSL and saw the issue, but a fresh build today that is very definitely Not SSL is running fine. My bad.

Wed Nov 18 10:49:35 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

Closing as all seems fine. (and IO::Poll bug has been worked around for some time now) -- Paul Evans

Wed Nov 18 10:49:36 2015 leonerd-cpan [...] leonerd.org.uk - Status changed from 'open' to 'rejected'