develooper Front page | perl.perl5.porters | Postings from September 2013

[perl #75156] Closing file handles early breaks IO::Select

Thread Previous | Thread Next
From:
Tony Cook via RT
Date:
September 18, 2013 02:12
Subject:
[perl #75156] Closing file handles early breaks IO::Select
Message ID:
rt-3.6.HEAD-1873-1379470318-430.75156-15-0@perl.org
On Tue Jan 03 19:06:13 2012, jkeenan wrote:
> On Tue May 18 00:35:01 2010, bre@klaki.net wrote:
> > (re-posting what I sent to perl5-porters: the IO::Select perldoc
> > should probably recommend perlbug and not perl5-porters as a venue
> > for bug-reports).
> > 
> > I write to you, because I think I have found and fixed a rather
> > nasty (and old) bug in IO::Select:
> > 
> > The bug is: IO::Select currently assumes that an IO::Handle will
> > always have a valid file descriptor, which is not actually the case.
> > If you add a handle and the handle later loses its file descriptor
> > (for whatever reason, this appears to be out of the control of the
> > programmer), then IO::Select will stop working and there is no way
> > to remove the broken descriptor, because the add/remove code
> > assumes fileno() will return something useful. The workaround in
> > my code today is to throw away the IO::Select object and build a
> > new one.
> > 
> > Attached is a sample program which triggers the bug, and a proposed
> > modification to IO::Select (NewSelect.pm) which I think should fix
> > the problem.  In case I fail to attach the files correctly, they
> > can also be found here:
> > 
> >   http://bre.klaki.net/programs/Perl-IO-Select-Bug/
> > 
> > 
> > Addition:
> > 
> > The real-world impact of this bug, is to cause most servers written
> > using IO::Select to go into infinite CPU-sucking loops when a
> > watched file-handle is closed without being removed from IO::Select
> > first.  My fix does not actually prevent that entirely, but it does
> > give the programmer a mechanism for dealing with the problem and
> > makes code slightly more resiliant - as long as the file handle
> > closure is detected *somewhere* and removed from IO::Select
> > *sometime* the system will recover.
> > 
> > 
> 
> This older ticket is difficult to evaluate because the attachments the
> author intended to attach never made it.  I went to the web site
> provided and downloaded those files.  With slight modifications, I tried
> them out and am attaching them.
> 
> Nevertheless, I can't reproduce the poster's complaint about IO::Select,
> that is, the 'remove' method seems to be succeeding, whereas the
> poster's comments suggest that it should be failing.  See my attachment,
> 75156_select.t.

There's a partial fix for this issue in 2e6546ca, unfortunately that fix
has a couple of bugs:

- it doesn't update the bit vector ($bits) so the next can_read() will
attempt to wait on a closed selector

- it doesn't update $count, so remove returns failure even though the FH
was (buggily) removed

Tony


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=75156

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About