Old $Response objects being cached by compiled code comes up
for things like subroutines being used in scripts.
Please see
http://www.apache-asp.org/style.html#Do%20not%20definc430b103
This is what I mean when mentioning using UseStrict and PerlWarn
to catch these closure problems. The problem more generally has
to do with closure & scoping issues.
If this does not have to do with subs defined in scripts then
please post the script that is having these errors as this might
shed some light.
--Josh
George Schlossnagle wrote:
On Tuesday, January 21, 2003, at 02:53 PM, Josh Chamas wrote:
Theo E. Schlossnagle wrote:
Josh Chamas wrote:
This is when an old $Response object is no longer valid. This is
normally
caused by my closure or bad scoping issues.
I assumed as much. However, it seems that:
sub AppendToLog { shift->{asp}->Log(...); }
should bde
sub AppendToLog {
my $self = shift;
if($self && $self->{asp}) {
$self->{asp}->Log(...);
}
}
in Response.pm. Why? My $Response variable still exists and as I
don't call Log directly it seems that it shouldn't return such a hard
error (die) when Apache::ASP makes that call internally.
No, $Response is no longer valid, and has been destroyed
during a prior request phase. It has only been cached incorrectly,
and this error results. Any use of $Response at this point would
be incorrect, so it does not make sense to spare the error with
a test for $Response->{asp}
Perhaps Theo was unclear. This code block is part of Apache::ASP
itself, not part of the userland code. We don't call this function
directly, it's invoked internally from within Apache::ASP.
Set these things to help catch these problems:
PerlSetVar UseStrict 1
PerlWarn On
I can do the later... But not the first. While we run both on almost
all our code bases, this particular code base is a legacy one
(written by another company) with over 200k lines of client .pm and
.asp files. (over 100k of custom perl modules alone). So,
retroactively adapting all legacy code to use strict is infeasible.
If you call Apache::ASP->Load() on all the files, you can find the
errors with UseStrict at compile time, so you do not get errors
at runtime. The process of converting over to UseStrict will catch
other errors besides the one that started this thread so would be
good for the code base to be converted to using.
Converting 100,000 lines of mission critical code is something we don't
have the luxury of doing. Although it is nasty, the code base works.
The apparent bug is in Apache::ASP
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
