Home > Archive > PERL POE > June 2005 > PoCoCl::UA related crash
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
PoCoCl::UA related crash
|
|
| Ed Heil 2005-06-08, 9:04 pm |
| Hi -- I'm pretty new to POE, and still getting my bearings, so I
apologize in advance for any vagueness and imprecision in this
question.
I'm working with a colleague on a client-server application which
previously used plain vanilla LWP to query the server, and recently
we've overhauled and POE-ified it and replaced the ordinary LWP with
PoCoCl::UA. (Version 0.06)
It works great most of the time, but every so often, the app will die
with a message that looks like this:
Can't use string ("") as a subroutine ref while "strict refs" in use at
/Library/Perl/5.8.1/POE/Component/Client/UserAgent.pm line 325.
(note that the line number is a bit off from the standard distribution
because I've been hacking up my copy of UserAgent.pm with debug output
around this point.)
I have not managed to duplicate this in any kind of a demo, but by
putting in debug messages I've got a clearer picture of the
circumstances which obtain when this happens.
It happens within POE/Component/Client/UserAgent.pm, of course, within
the subroutine "_pococ_ua_postback", on this line:
$entry -> postback -> ($request, $response, $entry);
It happens because $entry->postback is at this point "undef."
using the caller() function, I've found out $entry->postback becomes
"undef" under the following conditions:
LWP::Parallel::UserAgent::_perform_read(
), line 1153, calls
$self->on_failure
Po::Co::Cl::UserAgent::on_failure calls $object -> _pococ_ua_postback
At this point, _pococ_ua_postback calls $entry->postback, which is
defined and does NOT crash.
at this point, $entry->postback is, according to Data::Dumper:
$VAR1 = bless( sub { "DUMMY" }, 'POE::Session::Postback' );
Very soon thereafter, though:
LWP::Parallel::UserAgent::_perform_read(
), line 1171, calls
$self->on_return
Po::Co::Cl::UserAgent::on_return calls $object -> _pococ_ua_postback
At this point, _pococ_ua_postback calls $entry->postback, which is
undefined, and the app crashes.
at this point, $entry->postback is: $VAR1 = undef;
The problem does not occur except under these conditions --
_perform_read first fails, then calls the postback, and then succeeds,
and tries to call it again, and can't, because it's undef.
I definitely am not well enough versed in POE's guts to say whether
this is a problem with PoCoCl::UA or something about the postbacks
we're sending it or what.
If anyone could suggest some useful further steps to take to try to
figure out what is going on, I'd be very grateful.
This happens only sporadically, and it is less common when I'm on a
particularly fast, low-latency network connection and more common when
I'm on a slower one. So it may have something to do with the length of
time it takes for a request to return.
Thanks very much!
Ed Heil
| |
| David Davis 2005-06-08, 9:04 pm |
| I suggest reporting this bug:
http://rt.cpan.org/NoAuth/ReportBug... />
3AUseragent'
--
David Davis
Perl Programmer
http://teknikill.net/
Try CPAN Suggest!
http://cpan.teknikill.net/
On Thu, 27 Jan 2005 13:01:47 -0500, Ed Heil <ed@donorware.com> wrote:
> Hi -- I'm pretty new to POE, and still getting my bearings, so I
> apologize in advance for any vagueness and imprecision in this
> question.
>
> I'm working with a colleague on a client-server application which
> previously used plain vanilla LWP to query the server, and recently
> we've overhauled and POE-ified it and replaced the ordinary LWP with
> PoCoCl::UA. (Version 0.06)
>
> It works great most of the time, but every so often, the app will die
> with a message that looks like this:
>
> Can't use string ("") as a subroutine ref while "strict refs" in use at
> /Library/Perl/5.8.1/POE/Component/Client/UserAgent.pm line 325.
>
> (note that the line number is a bit off from the standard distribution
> because I've been hacking up my copy of UserAgent.pm with debug output
> around this point.)
>
> I have not managed to duplicate this in any kind of a demo, but by
> putting in debug messages I've got a clearer picture of the
> circumstances which obtain when this happens.
>
> It happens within POE/Component/Client/UserAgent.pm, of course, within
> the subroutine "_pococ_ua_postback", on this line:
>
> $entry -> postback -> ($request, $response, $entry);
>
> It happens because $entry->postback is at this point "undef."
>
> using the caller() function, I've found out $entry->postback becomes
> "undef" under the following conditions:
>
> LWP::Parallel::UserAgent::_perform_read(
), line 1153, calls
> $self->on_failure
> Po::Co::Cl::UserAgent::on_failure calls $object -> _pococ_ua_postback
> At this point, _pococ_ua_postback calls $entry->postback, which is
> defined and does NOT crash.
> at this point, $entry->postback is, according to Data::Dumper:
> $VAR1 = bless( sub { "DUMMY" }, 'POE::Session::Postback' );
>
> Very soon thereafter, though:
> LWP::Parallel::UserAgent::_perform_read(
), line 1171, calls
> $self->on_return
> Po::Co::Cl::UserAgent::on_return calls $object -> _pococ_ua_postback
> At this point, _pococ_ua_postback calls $entry->postback, which is
> undefined, and the app crashes.
>
> at this point, $entry->postback is: $VAR1 = undef;
>
> The problem does not occur except under these conditions --
> _perform_read first fails, then calls the postback, and then succeeds,
> and tries to call it again, and can't, because it's undef.
>
> I definitely am not well enough versed in POE's guts to say whether
> this is a problem with PoCoCl::UA or something about the postbacks
> we're sending it or what.
>
> If anyone could suggest some useful further steps to take to try to
> figure out what is going on, I'd be very grateful.
>
> This happens only sporadically, and it is less common when I'm on a
> particularly fast, low-latency network connection and more common when
> I'm on a slower one. So it may have something to do with the length of
> time it takes for a request to return.
>
> Thanks very much!
>
> Ed Heil
>
>
| |
|
|
|
|
|