Open
Description
Migrated from rt.cpan.org#93107 (status was 'new')
Requestors:
Attachments:
From leonerd-cpan@leonerd.org.uk on 2014-02-18 01:51:18:
IO::Poll uses IO objects as keys in internal hashes, relying therefore on the stringification of these IO handles to be stable.
The use of IO::Socket::SSL and late-upgrade after creation breaks this logic. For better or worse, IO::Socket::SSL->SSL_upgrade performs a rebless operation on the IO handle object, thus changing its stringification.
This bug manifests itself when using SSL upgrades on IO::Poll-multiplexed sockets, causing a 100% CPU spin the first time a socket is closed. The different stringification of the object handle means that $poll->remove() doesn't successfully remove it, causing the underlying poll(2) call to the kernel to still request a now-invalid file descriptor, causing it to return instantly with POLLNVAL.
I would suggest instead all uses of {$io} as a hash key be replaced with {refaddr $io}, because the refaddr of an object /is/ guaranteed inviolate during its lifetime.
--
Paul Evans
From leonerd-cpan@leonerd.org.uk on 2014-02-18 01:55:35:
On Mon Feb 17 20:51:18 2014, PEVANS wrote:
> I would suggest instead all uses of {$io} as a hash key be replaced
> with {refaddr $io}, because the refaddr of an object /is/ guaranteed
> inviolate during its lifetime.
As a side benefit, this would also defend against IO handles with stringification overload magic, which would otherwise either fail to identify, or would cause identity clashes if they overlapped.
--
Paul Evans
From leonerd-cpan@leonerd.org.uk on 2014-02-20 18:02:29:
On Mon Feb 17 20:51:18 2014, PEVANS wrote:
> I would suggest instead all uses of {$io} as a hash key be replaced
> with {refaddr $io}, because the refaddr of an object /is/ guaranteed
> inviolate during its lifetime.
Bugfix + regression test attached.
--
Paul Evans