Bug #76542 for POE: Use of uninitialized value $fd in exists at /usr/share/perl5/POE/Resource/FileHandles.pm line 577

Fri Apr 13 15:52:26 2012 fschlich [...] zedat.fu-berlin.de - Ticket created

Subject:

Use of uninitialized value $fd in exists at /usr/share/perl5/POE/Resource/FileHandles.pm line 577

Hi, when running the test suite for poe-component-client-http, I get two warnings: perl -w t/59_incomplete_b.t 1..4 ok 1 - got expected content-length request ok 2 - got expected no-content-length request Use of uninitialized value $fd in exists at /usr/share/perl5/POE/Resource/FileHandles.pm line 577. Use of uninitialized value $fd in exists at /usr/share/perl5/POE/Resource/FileHandles.pm line 577. ok 3 - length(content) triggered 406 ok 4 - content-length triggered 406 Looking at FileHandles.pm, I notice that _data_handle_remove() makes sure that $fd is defined when deregistering the handle with the kernel, but doesn't take similar precautions afterwards when removing the select from the session. Add a check there or short-circuit the entire sub when $fd is undef? Florian

Sun Apr 29 18:30:58 2012 RCAPUTO [...] cpan.org - Correspondence added

Hi, Florian. Can you reproduce the error at will? POE's APIs have a lot of error checking at the surface (in POE::Kernel), but they're disabled by default for speed. If you set the POE_ASSERT_USAGE environment variable, they'll all be enabled at compile time. If that doesn't give you a better failure message, I'll eat my hat. Or fix a bug. My choice. The POE_ASSERT_DEFAULT environment variable will enable all the internals checks, including those for memory leaks. I recommend it for development and field debugging, and any other times when the extra CPU hit isn't an issue. -- Rocco On Fri Apr 13 15:52:26 2012, fschlich wrote: Show quoted text

> Hi, > > when running the test suite for poe-component-client-http, I get two > warnings: > > perl -w t/59_incomplete_b.t > 1..4 > ok 1 - got expected content-length request > ok 2 - got expected no-content-length request > Use of uninitialized value $fd in exists at > /usr/share/perl5/POE/Resource/FileHandles.pm line 577. > Use of uninitialized value $fd in exists at > /usr/share/perl5/POE/Resource/FileHandles.pm line 577. > ok 3 - length(content) triggered 406 > ok 4 - content-length triggered 406 > > Looking at FileHandles.pm, I notice that _data_handle_remove() makes > sure that $fd is defined when deregistering the handle with the kernel, > but doesn't take similar precautions afterwards when removing the select > from the session. > > Add a check there or short-circuit the entire sub when $fd is undef? > > Florian

Sun Apr 29 18:31:00 2012 The RT System itself - Status changed from 'new' to 'open'

Fri May 04 18:14:04 2012 fschlich [...] zedat.fu-berlin.de - Correspondence added

Subject:	Re: [rt.cpan.org #76542] Use of uninitialized value $fd in exists at /usr/share/perl5/POE/Resource/FileHandles.pm line 577
Date:	Sat, 5 May 2012 00:13:53 +0200
To:	Rocco Caputo via RT <bug-POE [...] rt.cpan.org>
From:	Florian Schlichting <fschlich [...] ZEDAT.FU-Berlin.DE>

Hi Rocco, Show quoted text

> Can you reproduce the error at will?

well, yes of course, whenever I run t/59_incomplete_b.t from poe-component-client-http... What I was meaning to say is that as a Debian packager, I don't really know your module or the one where the test is from, so wouldn't know how come the file handle has become undef, but it struck me as odd that FileHandles.pm's _data_handle_remove() both checks for a defined $fd in its first block and forgets to do so in its second block. Perhaps it should start with something like return unless defined $fd; or add "defined $fd and" on line 577? Show quoted text

> If you set the POE_ASSERT_USAGE > environment variable, they'll all be enabled at compile time. If that doesn't give you a better > failure message, I'll eat my hat. Or fix a bug. My choice.

$ POE_ASSERT_USAGE=1 perl -w t/59_incomplete_b.t 1..4 ok 1 - got expected content-length request ok 2 - got expected no-content-length request (in cleanup) (9488) <us> invalid filehandle in select_read() at /usr/share/perl5/POE/Kernel.pm line 2143 POE::Kernel::select_read('POE::Kernel=ARRAY(0xed83b8)', 'GLOB(0x17365d8)') called at /usr/share/perl5/POE/Wheel/ReadWrite.pm line 392 POE::Wheel::ReadWrite::DESTROY('POE::Wheel::ReadWrite=ARRAY(0x1718960)') called at /usr/share/perl5/POE/Component/Client/HTTP.pm line 818 eval {...} called at /usr/share/perl5/POE/Component/Client/HTTP.pm line 818 POE::Component::Client::HTTP::_poco_weeble_io_read(undef, 'POE::Session=ARRAY(0x968ca8)', 'POE::Kernel=ARRAY(0xed83b8)', 'HASH(0x968ac8)', 'got_socket_input', 'POE::Session=ARRAY(0x968ca8)', undef, '/usr/share/perl5/POE/Wheel/ReadWrite.pm', 283, ...) called at /usr/share/perl5/POE/Session.pm line 464 POE::Session::_invoke_state('POE::Session=ARRAY(0x968ca8)', 'POE::Session=ARRAY(0x968ca8)', 'got_socket_input', 'ARRAY(0xe69280)', '/usr/share/perl5/POE/Wheel/ReadWrite.pm', 283, 'POE::Wheel::ReadWrite(13) -> select read') called at /usr/share/perl5/POE/Kok 3 - length(content) triggered 406 ernel.pm line 1731 POE::Kernel::call('POE::Kernel=ARRAY(0xed83b8)', 'POE::Session=ARRAY(0x968ca8)', 'got_socket_input', 'HTTP::Response=HASH(0x1740338)', 13) called at /usr/share/perl5/POE/Wheel/ReadWrite.pm line 283 POE::Wheel::ReadWrite::__ANON__(undef, 'POE::Session=ARRAY(0x968ca8)', 'POE::Kernel=ARRAY(0xed83b8)', 'HASH(0x968ac8)', 'POE::Wheel::ReadWrite(13) -> select read', 'POE::Session=ARRAY(0x968ca8)', undef, '/usr/share/perl5/POE/Resource/FileHandles.pm', 240,ok 4 - content-length triggered 406 ...) called at /usr/share/perl5/POE/Session.pm line 464 POE::Session::_invoke_state('POE::Session=ARRAY(0x968ca8)', 'POE::Session=ARRAY(0x968ca8)', 'POE::Wheel::ReadWrite(13) -> select read', 'ARRAY(0x171e6a8)', '/usr/share/perl5/POE/Resource/FileHandles.pm', 240, undef) called at /usr/share/perl5/POE/Kernel.pm line 1049 eval {...} called at /usr/share/perl5/POE/Kernel.pm line 1048 POE::Kernel::_dispatch_event('POE::Kernel=ARRAY(0xed83b8)', 'POE::Session=ARRAY(0x968ca8)', 'POE::Session=ARRAY(0x968ca8)', 'POE::Wheel::ReadWrite(13) -> select read', 1024, 'ARRAY(0x171e6a8)', '/usr/share/perl5/POE/Resource/FileHandles.pm', 240, undef, ...) called at /usr/share/perl5/POE/Resource/FileHandles.pm line 238 POE::Kernel::_data_handle_enqueue_ready(undef, undef, 30, 4) called at /usr/share/perl5/POE/Loop/Select.pm line 288 POE::Kernel::loop_do_timeslice('POE::Kernel=ARRAY(0xed83b8)') called at /usr/share/perl5/POE/Loop/Select.pm line 317 POE::Kernel::loop_run('POE::Kernel=ARRAY(0xed83b8)') called at /usr/share/perl5/POE/Kernel.pm line 1235 POE::Kernel::run('POE::Kernel') called at t/59_incomplete_b.t line 34 nice backtrace. "invalid filehandle" is correct, it's undef. Whether that's a bug I cannot say. What I opened this ticket about is that /usr/share/perl5/POE/Resource/FileHandles.pm:_data_handle_remove() goes on regardless, and uses that undef $fd as a hash key on line 579. Florian

Sun May 06 14:31:14 2012 RCAPUTO [...] cpan.org - Correspondence added

On Fri May 04 18:14:04 2012, fschlich wrote: Show quoted text

> > $ POE_ASSERT_USAGE=1 perl -w t/59_incomplete_b.t

[...] Show quoted text

> /usr/share/perl5/POE/Component/Client/HTTP.pm line 818

Is that the most recent CPAN release of POE::Component::Client::HTTP? The line numbers don't seem to match up with recent releases. Show quoted text

> nice backtrace. "invalid filehandle" is correct, it's undef. Whether > that's a bug I cannot say. What I opened this ticket about is that > /usr/share/perl5/POE/Resource/FileHandles.pm:_data_handle_remove() > goes > on regardless, and uses that undef $fd as a hash key on line 579.

It's definitely a bug. Undef should never be passed in. I'd like to find out why that's happening before addressing lower-level problems. The low-level error helps highlight problems at the higher level. They're almost like features. :) Unfortunately for me, the test case works here. Maybe the failure is triggered by your environment? It seems likely that something is nonstandard about your localhost interface. Is it firewalled to prevent random use? Is your localhost IPv6-only? Does it have a nonstandard address? Is it routed strangely, or not in your routing table at all? Anything like that?

Sun Jun 03 03:30:13 2012 RCAPUTO [...] cpan.org - Correspondence added

I think I fixed the underlying cause. I encountered the same error while running a routine test of POE::Component::Client::HTTP. I just release POE::Component::Client::HTTP 0.947, which should resolve this: commit 944c66f2149bc39a24db854d0310522b1d1697ed Author: Rocco Caputo <rcaputo@cpan.org> Date: Sun Jun 3 03:14:47 2012 -0400 [rt.cpan.org 76542] Fix a double close in PoCo::Client::HTTP. Florian Schlichting found POE throwing an error on an undefined file descriptor. POE::Component::Client::HTTP was closing a filehandle before destroying the wheel that was managing it. When it was time for the wheel to remove the filehandle's watcher, fileno() failed, and trouble ensued.

Sun Jun 03 03:30:15 2012 RCAPUTO [...] cpan.org - Status changed from 'open' to 'resolved'