Skip Menu |

This queue is for tickets about the POE CPAN distribution.

Report information
The Basics
Id: 67680
Status: resolved
Priority: 0/
Queue: POE

People
Owner: Nobody in particular
Requestors: troy [...] good.net
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.310
Fixed in: (no value)



Subject: Regression in 1.310?
Grettings, I have written a POE FTP server. Versions up to and including 1.299 seem to work fine. After upgrading to 1.310, My uploading seems not to work. The inbound data just doesn't seem to transfer, and eventually, I get a POE dump when the client times out and closes the tcp connections, with nothing obvious from my program above. Let me know if I can do anything to gather more information. === (24921) === Please address any warnings or errors above this message, and try again. If there are none, or those messages are from within POE, then please mail them along with the following information to bug-POE@rt.cpan.org: --- internal inconsistency (/2) ----- at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Resource/Sessions.pm line 191 POE::Kernel::_data_ses_free('POE::Kernel=ARRAY(0x3177158)', 2) called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Resource/Sessions.pm line 587 POE::Kernel::_data_ses_stop('POE::Kernel=ARRAY(0x3177158)', 2) called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Resource/Sessions.pm line 392 POE::Kernel::_data_ses_gc_sweep('POE::Kernel=ARRAY(0x3177158)') called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Resource/FileHandles.pm line 245 POE::Kernel::_data_handle_enqueue_ready(undef, undef, 8) called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Loop/Select.pm line 285 POE::Kernel::loop_do_timeslice('POE::Kernel=ARRAY(0x3177158)') called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Loop/Select.pm line 314 POE::Kernel::loop_run('POE::Kernel=ARRAY(0x3177158)') called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Kernel.pm line 1210 POE::Kernel::run('POE::Kernel=ARRAY(0x3177158)') called at ./ftpserver.pl line 612 This is perl 5, version 12, subversion 2 (v5.12.2) built for x86_64-linux (with 14 registered patches, see perl -V for more detail) Linux dev-apps-01 2.6.35-vs2.3.0.36.32-gentoo #2 SMP Sat Feb 26 10:41:36 MST 2011 x86_64 Intel(R) Xeon(R) CPU L5410 @ 2.33GHz GenuineIntel GNU/Linux
From: troy [...] good.net
As a side note, the test for POE::Component::Daemon appears to hang indefinitely on my system while under POE-1.310 but not POE-1.299, independent of my program. Thanks.
Subject: Re: [rt.cpan.org #67680] Regression in 1.310?
Date: Thu, 21 Apr 2011 17:11:44 -0700
To: bug-POE [...] rt.cpan.org
From: "perl [...] 0ne.us" <perl [...] 0ne.us>
Troy Ablan via RT wrote: Show quoted text
> Thu Apr 21 19:36:21 2011: Request 67680 was acted upon. > Transaction: Ticket created by tablan > Queue: POE > Subject: Regression in 1.310? > Broken in: 1.310 > Severity: Important > Owner: Nobody > Requestors: troy@good.net > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=67680 > > > > Grettings, > > I have written a POE FTP server. Versions up to and including 1.299 > seem to work fine. After upgrading to 1.310, My uploading seems not to > work. The inbound data just doesn't seem to transfer, and eventually, I > get a POE dump when the client times out and closes the tcp connections, > with nothing obvious from my program above. > > Let me know if I can do anything to gather more information. > > === (24921) === > Please address any warnings or errors above this message, and try > again. If there are none, or those messages are from within POE, > then please mail them along with the following information > to bug-POE@rt.cpan.org: > --- > internal inconsistency (/2) > ----- > at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Resource/Sessions.pm line 191 > POE::Kernel::_data_ses_free('POE::Kernel=ARRAY(0x3177158)', 2) > called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Resource/Sessions.pm > line 587 > POE::Kernel::_data_ses_stop('POE::Kernel=ARRAY(0x3177158)', 2) > called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Resource/Sessions.pm > line 392 > POE::Kernel::_data_ses_gc_sweep('POE::Kernel=ARRAY(0x3177158)') > called at > /usr/lib64/perl5/vendor_perl/5.12.2/POE/Resource/FileHandles.pm line 245 > POE::Kernel::_data_handle_enqueue_ready(undef, undef, 8) called > at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Loop/Select.pm line 285 > POE::Kernel::loop_do_timeslice('POE::Kernel=ARRAY(0x3177158)') > called at /usr/lib64/perl5/vendor_perl/5.12.2/POE/Loop/Select.pm line 314 > POE::Kernel::loop_run('POE::Kernel=ARRAY(0x3177158)') called at > /usr/lib64/perl5/vendor_perl/5.12.2/POE/Kernel.pm line 1210 > POE::Kernel::run('POE::Kernel=ARRAY(0x3177158)') called at > ./ftpserver.pl line 612 > > > This is perl 5, version 12, subversion 2 (v5.12.2) built for x86_64-linux > (with 14 registered patches, see perl -V for more detail) > > Linux dev-apps-01 2.6.35-vs2.3.0.36.32-gentoo #2 SMP Sat Feb 26 10:41:36 > MST 2011 x86_64 Intel(R) Xeon(R) CPU L5410 @ 2.33GHz GenuineIntel GNU/Linux >
Hello, Is it possible for you to provide the ftpserver.pl script ( slimmed down if you can ) and a way to trigger the dump? That way we can reproduce it locally and try to fix it. As a plus we might be able to integrate it into the testsuite so it'll never happen again :) I see you mentioned POE::Component::Daemon failing it's tests - do you use any other module in your server? Can you try each with 1.310 and see which ones fail? I can confirm that poco-daemon FAILs here too, and thats great news ( in a bad way hah ) - I've reported it: https://rt.cpan.org/Ticket/Display.html?id=67685 Maybe fixing the poco-daemon error will completely solve it for you, or not... Let's hope! :) Thanks again for reporting it! ~Apocalypse
Ideally we'd love to see a test case that can reproduce the problem under testing scenarios. We can turn around a fix much quicker if we can break the product at will and examine the pieces. If a test case can't be provided, please try running your server with these environment variables set: export POE_ASSERT_DATA=1 export POE_CATCH_EXCEPTIONS=0 The first environment variable will enable several runtime internal data consistency checks---not just on exit. The second will disable exception handling, which has been known to hide application errors for some undiagnosed reason. The checks and additional error messages may surface the problem quicker and in a more relevant location. Thank you.
Subject: Re: [rt.cpan.org #67680] Regression in 1.310?
Date: Thu, 05 May 2011 13:58:28 -0700
To: bug-POE [...] rt.cpan.org
From: Troy Ablan <troy [...] good.net>
Sorry for the delay. Just haven't had a chance to conjure up a suitable test case quite yet. The failing app isn't standalone and I'll have to whittle it down into something simpler in order to test separately. I have a suspicion it's related to POE::Component::Daemon, but haven't confirmed. I hope to have something to offer here by May 9 2011 (Monday). Thanks.
Subject: Re: [rt.cpan.org #67680] Regression in 1.310?
Date: Sun, 08 May 2011 19:29:34 -0700
To: bug-POE [...] rt.cpan.org
From: Troy Ablan <troy [...] good.net>
Two things 1) I have been unable to reproduce the problem after removing our backend bits. Something somewhat nonstandard that I do is I attach a tied filehandle to a ReadWrite wheel. In the case of reading, the FILENO method returns a filehandle opened to /dev/zero. For writing, I give it one to /dev/null. The tied filehandle backend streams files from mogilefs in chunks, from multiple backends, so AFAIK I'm forced to lie about the fileno in order to use POE wheels. 2) The problem/dump without the env variables shows up only when I try to retrieve a file. With these environment variables export POE_ASSERT_DATA=1 export POE_CATCH_EXCEPTIONS=0 everything still functions properly under POE-1.299, but doesn't even allow login as it barfs right away upon client connection under POE-1.310 with # ./ftpserver.pl 8484: Accept id: 1 IPv4 69.160.35.99:44792 at ./ftpserver.pl line 284. === (8492) === Please address any warnings or errors above this message, and try again. If there are none, or those messages are from within POE, then please mail them along with the following information to bug-POE@rt.cpan.org: --- <ev> can't enqueue event ``_sigchld_poll'' for nonexistent session ----- at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/Events.pm line 72 POE::Kernel::_data_ev_enqueue('POE::Kernel=ARRAY(0x2f16730)', 'POE::Kernel=ARRAY(0x2f16730)', 'POE::Kernel=ARRAY(0x2f16730)', '_sigchld_poll', 256, 'ARRAY(0x34097c0)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/Signals.pm', 549, undef, ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/Signals.pm line 547 POE::Kernel::_data_sig_enqueue_poll_event('POE::Kernel=ARRAY(0x2f16730)', 'CHLD') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Loop/PerlSignals.pm line 97 POE::Kernel::loop_watch_signal('POE::Kernel=ARRAY(0x2f16730)', 'CHLD') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/Signals.pm line 295 POE::Kernel::_data_sig_signal_watch('POE::Kernel=ARRAY(0x2f16730)', 2, 'CHLD') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/Signals.pm line 284 POE::Kernel::_data_sig_add('POE::Kernel=ARRAY(0x2f16730)', 'POE::Session=ARRAY(0x3408bb0)', 'CHLD', 'CHLD', 'ARRAY(0x340a958)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 697 POE::Kernel::sig('POE::Kernel=ARRAY(0x2f16730)', 'CHLD', 'CHLD') called at ./ftpserver.pl line 314 main::__ANON__(undef, 'POE::Session=ARRAY(0x3408bb0)', 'POE::Kernel=ARRAY(0x2f16730)', 'HASH(0x3408b20)', 'request', 'POE::Session=ARRAY(0x290a038)', undef, '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm', 700, ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Session.pm line 464 POE::Session::_invoke_state('POE::Session=ARRAY(0x3408bb0)', 'POE::Session=ARRAY(0x290a038)', 'request', 'ARRAY(0x340c808)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm', 700, 'update_status') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1028 eval {...} called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1014 POE::Kernel::_dispatch_event('POE::Kernel=ARRAY(0x2f16730)', 'POE::Session=ARRAY(0x3408bb0)', 'POE::Session=ARRAY(0x3408bb0)', 'request', 2, 'ARRAY(0x340c808)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm', 700, 'request', ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1714 POE::Kernel::call('POE::Kernel=ARRAY(0x2f16730)', 2, 'request', 'POE::Kernel=ARRAY(0x2f16730)', 'HASH(0x3408790)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 700 POE::Component::Daemon::expedite_signal('POE::Component::Daemon=HASH(0x33fc9d0)', 'daemon_child', 'HASH(0x3408790)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 712 POE::Component::Daemon::inform_others('POE::Component::Daemon=HASH(0x33fc9d0)', 'daemon_child', 'HASH(0x3408790)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 644 POE::Component::Daemon::become_child('POE::Component::Daemon=HASH(0x33fc9d0)', 0, 'HASH(0x3408790)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 578 POE::Component::Daemon::fork('POE::Component::Daemon=HASH(0x33fc9d0)', 'POE::Session=ARRAY(0x290a038)', 'POE::Kernel=ARRAY(0x2f16730)', 'HASH(0x33fd9b0)', 'fork', 'POE::Session=ARRAY(0x290a038)', undef, '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm', 849, ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Session.pm line 483 POE::Session::_invoke_state('POE::Session=ARRAY(0x290a038)', 'POE::Session=ARRAY(0x290a038)', 'fork', 'ARRAY(0x340bf28)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm', 849, 'request') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1707 POE::Kernel::call('POE::Kernel=ARRAY(0x2f16730)', 'POE::Session=ARRAY(0x290a038)', 'fork', 'HASH(0x3408790)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 849 POE::Component::Daemon::fork_off('POE::Component::Daemon=HASH(0x33fc9d0)', 'ARRAY(0x340bbc8)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 1044 POE::Component::Daemon::update_status_fork_parent('POE::Component::Daemon=HASH(0x33fc9d0)', 'req', 'HASH(0x3408790)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 948 POE::Component::Daemon::update_status('POE::Component::Daemon=HASH(0x33fc9d0)', 'POE::Session=ARRAY(0x290a038)', 'POE::Kernel=ARRAY(0x2f16730)', 'HASH(0x33fd9b0)', 'update_status', 'POE::Session=ARRAY(0x3408bb0)', undef, '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm', 1099, ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Session.pm line 483 POE::Session::_invoke_state('POE::Session=ARRAY(0x290a038)', 'POE::Session=ARRAY(0x3408bb0)', 'update_status', 'ARRAY(0x3409d48)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm', 1099, 'POE::Wheel::ListenAccept(1) -> select read') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1028 eval {...} called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1014 POE::Kernel::_dispatch_event('POE::Kernel=ARRAY(0x2f16730)', 'POE::Session=ARRAY(0x290a038)', 'POE::Session=ARRAY(0x3408bb0)', 'update_status', 2, 'ARRAY(0x3409d48)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm', 1099, 'request', ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1714 POE::Kernel::call('POE::Kernel=ARRAY(0x2f16730)', 'POE-Component-Daemon', 'update_status', 'req', 'HASH(0x3408790)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 1099 Daemon::update_status('Daemon', 'req', 'HASH(0x3408790)') called at ./ftpserver.pl line 288 main::__ANON__(undef, 'POE::Session=ARRAY(0x3408bb0)', 'POE::Kernel=ARRAY(0x2f16730)', 'HASH(0x3408b20)', 'accept', 'POE::Session=ARRAY(0x3408bb0)', undef, '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Wheel/ListenAccept.pm', 100, ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Session.pm line 464 POE::Session::_invoke_state('POE::Session=ARRAY(0x3408bb0)', 'POE::Session=ARRAY(0x3408bb0)', 'accept', 'ARRAY(0x2f9ed88)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Wheel/ListenAccept.pm', 100, 'request') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1707 POE::Kernel::call('POE::Kernel=ARRAY(0x2f16730)', 'POE::Session=ARRAY(0x3408bb0)', 'accept', 'GLOB(0x34071c8)', '\x{2}\x{0}\x{ae}\x{f8}E\x{a0}#c\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}', 1) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Wheel/ListenAccept.pm line 100 POE::Wheel::ListenAccept::__ANON__(undef, 'POE::Session=ARRAY(0x3408bb0)', 'POE::Kernel=ARRAY(0x2f16730)', 'HASH(0x3408b20)', 'POE::Wheel::ListenAccept(1) -> select read', 'POE::Session=ARRAY(0x3408bb0)', undef, '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/FileHandles.pm', 240, ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Session.pm line 464 POE::Session::_invoke_state('POE::Session=ARRAY(0x3408bb0)', 'POE::Session=ARRAY(0x3408bb0)', 'POE::Wheel::ListenAccept(1) -> select read', 'ARRAY(0x3406ef8)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/FileHandles.pm', 240, undef) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1036 eval {...} called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1035 POE::Kernel::_dispatch_event('POE::Kernel=ARRAY(0x2f16730)', 'POE::Session=ARRAY(0x3408bb0)', 'POE::Session=ARRAY(0x3408bb0)', 'POE::Wheel::ListenAccept(1) -> select read', 1024, 'ARRAY(0x3406ef8)', '/usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/FileHandles.pm', 240, undef, ...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/FileHandles.pm line 238 POE::Kernel::_data_handle_enqueue_ready(undef, undef, 3) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Loop/Select.pm line 285 POE::Kernel::loop_do_timeslice('POE::Kernel=ARRAY(0x2f16730)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Loop/Select.pm line 314 POE::Kernel::loop_run('POE::Kernel=ARRAY(0x2f16730)') called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Kernel.pm line 1210 POE::Kernel::run('POE::Kernel=ARRAY(0x2f16730)') called at ./ftpserver.pl line 612
On Sun May 08 22:29:46 2011, tablan wrote: Show quoted text
> Two things > > 1) I have been unable to reproduce the problem after removing our > backend bits. Something somewhat nonstandard that I do is I attach a > tied filehandle to a ReadWrite wheel. In the case of reading, the > FILENO method returns a filehandle opened to /dev/zero. For writing, > I > give it one to /dev/null. The tied filehandle backend streams files > from mogilefs in chunks, from multiple backends, so AFAIK I'm forced > to > lie about the fileno in order to use POE wheels.
I'm almost certain that your hack to provide fileno() is *not* the issue here. The worst you may have done is turned the once-event-driven ReadWrite object into a high-CPU poller by watching filehandles that are always ready for read/write. Show quoted text
> 2) The problem/dump without the env variables shows up only when I try > to retrieve a file. With these environment variables > > export POE_ASSERT_DATA=1 > export POE_CATCH_EXCEPTIONS=0 > > everything still functions properly under POE-1.299, but doesn't even > allow login as it barfs right away upon client connection under > POE-1.310 with
[...] <ev> can't enqueue event ``_sigchld_poll'' for nonexistent session at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/Events.pm line 72 POE::Kernel has failed to send itself an event. POE::Kernel may not have been created, or it may have self-destructed at an inopportune time. [...] POE::Kernel::_data_sig_enqueue_poll_event(...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Loop/PerlSignals.pm line 97 The event loop POE::Kernel is using has been asked to watch SIGCHLD. It's trying to enqueue "_sigchld_poll" to start that process. [...] POE::Kernel::loop_watch_signal(...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Resource/Signals.pm line 295 POE is trying to defer SIGCHLD by sending an event as part [...] POE::Kernel::sig('POE::Kernel=ARRAY(0x2f16730)', 'CHLD', 'CHLD') called at ./ftpserver.pl line 314 Your ftpserver.pl program is calling sig() to handle SIGCHLD at line 314. Something about the way you're calling it may be an issue. If you can't show your whole ftpserver.pl program, then I recommend looking around there for the issue. [...] POE::Kernel::call(...) called at /usr/lib64/perl5/vendor_perl/5.12.3/POE/Component/Daemon.pm line 700 The problem may have something to do with POE::Component::Daemon. You might be able to isolate the problem by focusing on that module's usage. I can't help more than that without more information.
This ticket is at an impasse. Downgrading to "stalled". It may be rejected in the future unless the requester (and/or other people) provides enough information to make headway on the problem.
From: troy [...] good.net
Sorry for stalling on this so long. It's been easier just to keep pushing this problem aside and stay on the old version of POE but finally actively set aside some time for this. Attached is a minimal demo that demostrates the regression == 1.289 == # ./poe-breaker.pl warble warble warble warble warble EOF at ./poe-breaker.pl line 32. == 1.350 == # ./poe-breaker.pl <hang with no output until ^C>
Subject: poe-breaker.pl
#!/usr/bin/perl package main; use warnings; use strict; use POE; use POE::Filter::Stream; use POE::Wheel::ReadWrite; POE::Session->create( inline_states => { _start => sub { my $fh = do { no warnings; local *FH }; tie $fh, 'ReadHandle'; $_[HEAP]->{octagon} = POE::Wheel::ReadWrite->new( Handle => $fh, Filter => POE::Filter::Stream->new(), InputEvent => 'file_input', ErrorEvent => 'file_error', ); }, file_input => sub { print $_[ARG0]; }, file_error => sub { warn "EOF"; delete $_[HEAP]->{octagon}; } } ); $poe_kernel->run(); package ReadHandle; use warnings; use strict; use IO::File; sub TIEHANDLE { my $class = shift; my $devzero = IO::File->new; $devzero->open("< /dev/zero"); my $self = { devzero => $devzero }; bless $self, $class; return $self; } sub FILENO { return $_[0]->{devzero}->fileno; } { # closures are fun my $times = 0; sub READ { my $buff = \$_[1]; if ($times++ >= 5) { return undef; } else { $$buff = "warble\n"; return 7; } } }
I don't know why yet, but it works much better when you have C<Handle => \$fh>. That is, pass in a reference to the filehandle glob; not the glob itself.
Alternatively: use Symbol qw(gensym); my $fh = gensym(); tie *$fh, 'ReadHandle'; ... Handle => $fh,
The issue is purely Perl: One can't call $fh->blocking(0) on the $fh you've made.
All that said, I was able to find a work-around that won't require you to change code. This will be in 1.351. commit 2dceb43e64faba7df175bdf9ffc0dda7648f0fb6 Author: Rocco Caputo <rcaputo@cpan.org> Date: Sun Mar 11 11:32:46 2012 -0400 [rt.cpan.org 67680] Use IO::Handle::blocking() rather than $fh->blocking(). Some file handles, such as my $fh = do { no warnings; local *FH }; can't be used as IO::Handle objects. IO::Handle::blocking($fh) seems to work, though. This was caught by Troy, who was nice enough to open the bug. Thanks!