Bug #21172 for POE-Component-Client-HTTP: Can't call method "create

Thu Aug 24 16:49:03 2006 rataxis [...] cpan.org - Ticket created

Subject:	Can't call method "create_timer" on unblessed reference
Date:	Thu, 24 Aug 2006 21:48:38 +0100
To:	bug-poe-component-client-http [...] rt.cpan.org
From:	Joel Bernstein <joel [...] fysh.org>

Hi Rocco, We seem to have uncovered an odd bug in POE::Component::Client::HTTP::poco_weeble_connect_done() Can't call method "create_timer" on unblessed reference at /usr/local/share/perl/5.8.7/POE/Component/Client/HTTP.pm line 265. This error is reproducible, but in a very transitory way - we do the exact same request n times (where n can be 3..50, say) without error, but then POE crashes with the stacktrace below. Bizarrely, we can have runs of the application where it is impossible to provoke a crash, and runs where it crashes very regularly. I can't get my head around this and would love to prove that it is my application causing the error. It is so transitory, in fact, that I almost think it's either a Perl bug or a problem with a remote HTTP server, but none of these seems awfully likely. I know that isn't much of a bug report, please let me know (joel on #poe on MAGnet/Rhizomatic IRC) whether there's anything else I can gather for you. I'll try to put together a minimal test case tomorrow if I have the tuits but I'm not confident that I can reproduce this at will... I have upgraded POE from 0.36 to 0.3601. This seems to have lowered the chances of the error occurring, but that may be a red herring. VERSIONS: Perl 5.8.7 and 5.8.8 POE 0.3601 and 0.36 POE::Component::Connection::Keepalive 1.0060 POE::Component::Client::HTTP 0.77 POE::Component::Client::Keepalive 0.0801 POE::Component::Client::DNS 0.99 STACKTRACE: 2 -> _child (from /usr/local/share/perl/5.8.8/POE/Resource/Sessions.pm at 495) Can't call method "create_timer" on unblessed reference at /usr/local/share/perl/5.8.8/POE/Component/Client/HTTP.pm line 265. <us> must call select() from a running session at /usr/local/share/perl/5.8.8/POE/Kernel.pm line 2068 POE::Kernel::select('POE::Kernel=ARRAY(0x84f202c)', 'GLOB(0x90bf790)') called at /usr/local/share/perl/5.8.8/POE/Wheel/ReadWrite.pm line 391 POE::Wheel::ReadWrite::DESTROY('POE::Wheel::ReadWrite=ARRAY(0x90b5ce0)') called at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 eval {...} called at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 POE::Component::Connection::Keepalive::DESTROY('POE::Component::Connection::Keepalive=ARRAY(0x9041b54)') called at -e line 0 eval {...} called at -e line 0 (in cleanup) <us> must call select() from a running session at /usr/local/share/perl/5.8.8/POE/Kernel.pm line 2068 POE::Kernel::select('POE::Kernel=ARRAY(0x84f202c)', 'GLOB(0x90bf790)') called at /usr/local/share/perl/5.8.8/POE/Wheel/ReadWrite.pm line 391 POE::Wheel::ReadWrite::DESTROY('POE::Wheel::ReadWrite=ARRAY(0x90b5ce0)') called at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 eval {...} called at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 POE::Component::Connection::Keepalive::DESTROY('POE::Component::Connection::Keepalive=ARRAY(0x9041b54)') called at -e line 0 eval {...} called at -e line 0 <us> must call select() from a running session at /usr/local/share/perl/5.8.8/POE/Kernel.pm line 2068 POE::Kernel::select('POE::Kernel=ARRAY(0x84f202c)', 'GLOB(0x905316c)') called at /usr/local/share/perl/5.8.8/POE/Wheel/ReadWrite.pm line 391 POE::Wheel::ReadWrite::DESTROY('POE::Wheel::ReadWrite=ARRAY(0x90bf1c0)') called at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 eval {...} called at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 POE::Component::Connection::Keepalive::DESTROY('POE::Component::Connection::Keepalive=ARRAY(0x905d1b4)') called at -e line 0 eval {...} called at -e line 0 (in cleanup) <us> must call select() from a running session at /usr/local/share/perl/5.8.8/POE/Kernel.pm line 2068 POE::Kernel::select('POE::Kernel=ARRAY(0x84f202c)', 'GLOB(0x905316c)') called at /usr/local/share/perl/5.8.8/POE/Wheel/ReadWrite.pm line 391 POE::Wheel::ReadWrite::DESTROY('POE::Wheel::ReadWrite=ARRAY(0x90bf1c0)') called at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 eval {...} called at /usr/local/share/perl/5.8.8/POE/Component/Connection/Keepalive.pm line 44 POE::Component::Connection::Keepalive::DESTROY('POE::Component::Connection::Keepalive=ARRAY(0x905d1b4)') called at -e line 0 eval {...} called at -e line 0 <us> must call select() from a running session at /usr/local/share/perl/5.8.8/POE/Kernel.pm line 2068 POE::Kernel::select('POE::Kernel=ARRAY(0x84f202c)', 'GLOB(0x8d8fcd4)') called at /usr/local/share/perl/5.8.8/POE/Wheel/ReadWrite.pm line 391 POE::Wheel::ReadWrite::DESTROY('POE::Wheel::ReadWrite=ARRAY(0x8d90394)') called at -e line 0 eval {...} called at -e line 0 (in cleanup) <us> must call select() from a running session at /usr/local/share/perl/5.8.8/POE/Kernel.pm line 2068 POE::Kernel::select('POE::Kernel=ARRAY(0x84f202c)', 'GLOB(0x8d8fcd4)') called at /usr/local/share/perl/5.8.8/POE/Wheel/ReadWrite.pm line 391 POE::Wheel::ReadWrite::DESTROY('POE::Wheel::ReadWrite=ARRAY(0x8d90394)') called at -e line 0 eval {...} called at -e line 0 <us> must call select() from a running session at /usr/local/share/perl/5.8.8/POE/Kernel.pm line 2068 POE::Kernel::select('POE::Kernel=ARRAY(0x84f202c)', 'GLOB(0x8d7ce24)') called at /usr/local/share/perl/5.8.8/POE/Wheel/SocketFactory.pm line 1120 POE::Wheel::SocketFactory::_shutdown('SCALAR(0x8d7cef0)', 'REF(0x8d7ce60)', 'SCALAR(0x8d7ce9c)', 'SCALAR(0x8d7cea8)', 'SCALAR(0x8d7ceb4)', 'SCALAR(0x8d7ce78)', 'SCALAR(0x8d7cec0)', 'SCALAR(0x8d7ce84)') called at /usr/local/share/perl/5.8.8/POE/Wheel/SocketFactory.pm line 1098 POE::Wheel::SocketFactory::DESTROY('POE::Wheel::SocketFactory=ARRAY(0x8d7ce54)') called at -e line 0 eval {...} called at -e line 0 (in cleanup) <us> must call select() from a running session at /usr/local/share/perl/5.8.8/POE/Kernel.pm line 2068 POE::Kernel::select('POE::Kernel=ARRAY(0x84f202c)', 'GLOB(0x8d7ce24)') called at /usr/local/share/perl/5.8.8/POE/Wheel/SocketFactory.pm line 1120 POE::Wheel::SocketFactory::_shutdown('SCALAR(0x8d7cef0)', 'REF(0x8d7ce60)', 'SCALAR(0x8d7ce9c)', 'SCALAR(0x8d7cea8)', 'SCALAR(0x8d7ceb4)', 'SCALAR(0x8d7ce78)', 'SCALAR(0x8d7cec0)', 'SCALAR(0x8d7ce84)') called at /usr/local/share/perl/5.8.8/POE/Wheel/SocketFactory.pm line 1098 POE::Wheel::SocketFactory::DESTROY('POE::Wheel::SocketFactory=ARRAY(0x8d7ce54)') called at -e line 0 eval {...} called at -e line 0 zsh: exit 255 ./scripts/backend.sh

Tue Sep 05 12:32:49 2006 RCAPUTO [...] cpan.org - Correspondence added

From:

RCAPUTO [...] cpan.org

On Thu Aug 24 16:49:03 2006, rataxis wrote: Show quoted text

> Hi Rocco, > > We seem to have uncovered an odd bug in > POE::Component::Client::HTTP::poco_weeble_connect_done() > > Can't call method "create_timer" on unblessed reference at > /usr/local/share/perl/5.8.7/POE/Component/Client/HTTP.pm line 265.

I've attached a test case that triggers this error every time.

Download joel-cancel-test.perl
application/octet-stream 613b

Message body not shown because it is not plain text.

Tue Sep 05 12:32:51 2006 The RT System itself - Status changed from 'new' to 'open'

Wed Sep 20 16:41:43 2006 APOCAL [...] cpan.org - Correspondence added

<joel> ooh. dngor, can we talk about RT 21172 quickly? iirc you had outlined a fix to me, involving significant changes to how PoCoClHTTP aand PoCoClKeepalive interact... but i never made any notes on it <joel> in fact, if you can add a note to the bug about what you suggested, i can see about making up patches. <LordVorp> does PoCoClHTTP speak gzip compression yet? <dngor> joel: Augh! * dngor dredges through his mind. <joel> dngor : I don't have logs of the original chat about it :/ <joel> you suggested some way for PoCoClHTTP to cancel a connection req when trying to cancel a http req, i think <dngor> Yeah. Client::Keepalive needs a way to cancel requests that are still in a connection-pending state. That is, the socket's been built, connect() has been called, but it hasn't made the connection yet. <joel> right. in my case, that happens due to firewalls dropping rather than rejecting, typically. <joel> it's an edge case, but an important one... <joel> how does Client::HTTP know if the connection has succeded? <dngor> It gets back a connection object. <joel> should Cl::KA inform it, and then Cl::HTTP enqueues reqs until it's informed of a successful connection? <joel> ah, OK. <LordVorp> that should simplify things <joel> so it only needs a patch to Cl::HTTP then, not Cl::KA too? <joel> am I conflating two different previously-discussed fixes ttogether? <dngor> As far as I know, there's no way to tell Cl::KA to stop a connection that's already in progress. <dngor> POE::Stage makes this thing trivial, although there's no HTTP client for it yet. Destroy your request object, and everything allocated as a result of it gets cleaned up. Even in subservient stages. <joel> Stage? <joel> another Session? <joel> ah, it's on CPAN <buu> Yay scary sessions. <joel> dngor : wait. then there's another bug just waiting to be exposed by this one. <joel> if you can cancel a req which hasn't yet got a connection object, what happens if it is subsequently handed a connection objwect for which there's no req, because the Req was cancelled? * _Pingu_ has quit (Quit: Bye) <agaran> re <dngor> joel: That would be a race condition. Maybe the cancellation request (and connection object return) should be synchronous. <joel> dngor : is it possible to return a connection object marked as cancelled? you said yourself that Cl::KA can't be cancelled. <joel> so I don't see how you /could/ make it synchronous without patching Cl::KA to support that behaviour. <dngor> There'd be no point in returning a connection object for a canceled request. <LordVorp> unless of course the algorithm instantiating it can't handle NOT having a valid connection *object* ? <joel> no. but you'd need some way to inform Cl::KA that it shouldn't return a connection object. or else how does Cl::HTTP know what to do when the race condition hits? <Apocalypse> Just let it return and drop the "unknown" object? <dngor> I think it's desirable to have a way to tell Cl::KA not to bother finishing a connection. <Apocalypse> yeah but you still need to do both because of race conditions <dngor> Why not fix the race condition? <joel> fair enough <Apocalypse> whatever - but I never liked forced synchrony :) <joel> can you be bothered to jot this stuff onto the bug? <joel> if so i'll work on it tomorrow. but i need to go home now. <dngor> I'll need to do it later, like when I'm not at work. <Apocalypse> I can do it -- ~Apocalypse

Sat Apr 19 18:35:58 2008 RCAPUTO [...] cpan.org - Correspondence added

Appears to have been fixed. You wrote: Show quoted text

> I've attached a test case that triggers this error every time.

The test case doesn't crash: 1) poerbook:~/projects/poco-client-http% perl joel-cancel-test.perl 408 Request Timeout <html> <HEAD><TITLE>Error: Request Timeout</TITLE></HEAD> <BODY> <H1>Error: Request Timeout</H1> Request timed out (component shut down) </BODY> </HTML> 1) poerbook:~/projects/poco-client-http%

Sat Apr 19 18:36:01 2008 RCAPUTO [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #21172 for POE-Component-Client-HTTP: Can't call method "create_timer" on unblessed reference