You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jonathan Field <jo...@binadopta.com> on 2003/12/02 01:02:06 UTC
[BUG] Inconsistent $r->print() behavior with references
Hi all,
This is my first mod_perl bug report, so I'd like to start by thanking you
all for your great work over the years.
The problem I am experiencing involves passing a scalar reference (instead
of a scalar) to $r->print(). It usually works as documented. However I
have come across a situation where instead of printing the contents, it
prints the string version of the ref itself: "SCALAR(0x8ca70e4)".
After some research, it seems that I can trigger this behavior by doing a
certain type of regex on the scalar reference, specifically: a successful
regex that includes a backreference.
Here is a short handler that demonstrates:
package reftest;
use strict;
use warnings;
sub handler {
my $r = shift;
$r->send_http_header("text/plain");
my $data = "hello\n";
my $dataref = \$data;
# normally we can pass a reference to Apache's print
$r->print($dataref);
$$dataref =~ s/(h)/$1/;
# but not if we've done a successful backreferenced pattern match
$r->print($dataref);
}
1;
And in the conf file:
PerlRequire /path/to/file/reftest.pl
<Location /reftest>
SetHandler perl-script
PerlHandler reftest
</Location>
On the first request to a given child, I get:
hello
SCALAR(0x8ca70e4)
On subsequent requests I get:
SCALAR(0x8ca70e4)SCALAR(0x8ca70e4)
There are no messages in the error log when this happens. I am using
Apache/1.3.28 (Unix) mod_perl/1.28 mod_ssl/2.8.15 OpenSSL/0.9.7b under
FreeBSD 4.6.2-release. The output of perl -V is below.
Thanks in advance for your time, let me know if you need any further
information!
Jonathan Field
-------------------
--- perl -V output:
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=freebsd, osvers=4.6.2-release, archname=i386-freebsd
uname='freebsd dev1.zappos.com 4.6.2-release freebsd 4.6.2-release #0:
wed aug 14 21:23:26 gmt 2002
murray@builder.freebsdmall.com:usrsrcsyscompilegeneric i386 '
config_args='-sde -Dprefix=/usr/home/zappos/zappos.com/perl
-Darchlib=/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1/mach
-Dprivlib=/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1
-Dman3dir=/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1/man/man3
-Dsitearch=/usr/home/zappos/zappos.com/perl/lib/perl5/site_perl/5.6.1/mach
-Dsitelib=/usr/home/zappos/zappos.com/perl/lib/perl5/site_perl/5.6.1
-Ui_malloc -Ui_iconv
-Dccflags=-DAPPLLIB_EXP="/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1/BSDPAN"
-Ui_gdbm -Dusemymalloc=n'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags
='-DAPPLLIB_EXP="/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1/BSDPAN"
-fno-strict-aliasing -I/usr/local/include',
optimize='-O -pipe ',
cppflags='-DAPPLLIB_EXP="/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1/BSDPAN"
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lc -lcrypt -lutil
perllibs=-lm -lc -lcrypt -lutil
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under freebsd
Compiled at Aug 21 2002 18:35:52
@INC:
/usr/home/zappos/zappos.com/perl/lib/perl5/site_perl/5.6.1/mach
/usr/home/zappos/zappos.com/perl/lib/perl5/site_perl/5.6.1
/usr/home/zappos/zappos.com/perl/lib/perl5/site_perl
/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1/BSDPAN
/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1/mach
/usr/home/zappos/zappos.com/perl/lib/perl5/5.6.1
.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Geoffrey Young wrote:
> >>I think the issue is that after your manipulations $dataref is no longer a
> >>plain PV. I used Devel::Peek to look at $dataref before and after and it
> >>changes from a PV to PVMG. where this trips up mod_perl is in
> >>Apache::write_client:
> >>
> >> SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
> >
> >
> > At first sight, a >= looks more correct here -----------^^
>
> ah, cool - I didn't realize you could do that (though I guess it makes sense
> when you think about it :)
>
> but do you really want to derefernce a SVt_PVFM? the implications here are
> far beyond my reach.
That's a common idiom in the perl core -- hence my "at first sight".
A couple of bugs were fixed like this.
I usually stay carefully far from formats :)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Rafael Garcia-Suarez wrote:
> Geoffrey Young wrote:
>
>>I think the issue is that after your manipulations $dataref is no longer a
>>plain PV. I used Devel::Peek to look at $dataref before and after and it
>>changes from a PV to PVMG. where this trips up mod_perl is in
>>Apache::write_client:
>>
>> SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
>
>
> At first sight, a >= looks more correct here -----------^^
ah, cool - I didn't realize you could do that (though I guess it makes sense
when you think about it :)
but do you really want to derefernce a SVt_PVFM? the implications here are
far beyond my reach.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Geoffrey Young wrote:
> I think the issue is that after your manipulations $dataref is no longer a
> plain PV. I used Devel::Peek to look at $dataref before and after and it
> changes from a PV to PVMG. where this trips up mod_perl is in
> Apache::write_client:
>
> SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
At first sight, a >= looks more correct here -----------^^
> (SV*)SvRV(ST(i)) : ST(i);
>
> so, if the scalar reference to be printed isn't of type SVt_PV it does not
> get dereferenced.
>
> I suppose we could change that to a SvPOK check instead, but I'm really not
> inclined to change anything here - doug has said several times that the
> magical dereferencing in $r->print() was a bad idea and should be considered
> deprecated. it's not in 2.0 either, so you'll need to dereference yourself
> in order to port your code (someday :)
your call :) (I wasn't ever aware of this magical dereference thing)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Jonathan Field <jo...@binadopta.com>.
Thanks for the info. It all makes some sort of sense :)
Jonathan Field
On Tue, 2 Dec 2003, Rafael Garcia-Suarez wrote:
> Jonathan Field wrote:
> > I was surprised that the "SCALAR(0x8ca70e4)" output was identical on
> > subsequent requests to a child -- indicating to me that the ref (and what
> > it was refering to) may have survived the request cycle? I guess would
> > have expected a different ref, especially after running through the top
> > part of the handler again, where it reinitializes them. I've included the
> > code again below for convenience).
>
> To avoid allocating and reallocating lexical variables, perl
> preallocates memory pads for them, in which they are stored. perl knows
> how to allocate the pads and to which lexical scope to attach them via
> the my() compile-time declaration. So, it's not surprising the address
> of this value doesn't change between runs.
>
> > Also, the internal magic (switching from PV to PVMG) seems to survive the
> > request cycle? Regardlesss of whether the $r->print() behavior is going
> > to be changed, I was surprised that the regex from first request effected
> > the behavior on the second request.
>
> Yes, this magic is used to attach matching positions to a string, or
> something like that (can't remember precisely). Since the string
> "hello\n" isn't destroyed between runs of the handler, magic stays
> there. This is an unfortunate side-effect of pattern matching. Getting
> rid of it would be a good thing, -- but would probably involve lots of
> work on the scary regex engine.
>
> --
> Reporting bugs: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Jonathan Field wrote:
> I was surprised that the "SCALAR(0x8ca70e4)" output was identical on
> subsequent requests to a child -- indicating to me that the ref (and what
> it was refering to) may have survived the request cycle? I guess would
> have expected a different ref, especially after running through the top
> part of the handler again, where it reinitializes them. I've included the
> code again below for convenience).
To avoid allocating and reallocating lexical variables, perl
preallocates memory pads for them, in which they are stored. perl knows
how to allocate the pads and to which lexical scope to attach them via
the my() compile-time declaration. So, it's not surprising the address
of this value doesn't change between runs.
> Also, the internal magic (switching from PV to PVMG) seems to survive the
> request cycle? Regardlesss of whether the $r->print() behavior is going
> to be changed, I was surprised that the regex from first request effected
> the behavior on the second request.
Yes, this magic is used to attach matching positions to a string, or
something like that (can't remember precisely). Since the string
"hello\n" isn't destroyed between runs of the handler, magic stays
there. This is an unfortunate side-effect of pattern matching. Getting
rid of it would be a good thing, -- but would probably involve lots of
work on the scary regex engine.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Jonathan Field <jo...@binadopta.com>.
> But anyway, just thought I'd comment that the reason I think most mod_perl
> developers would think to use that functionality would be memory, rather
> than speed. Pretty much all of our mod_perl servers are memory bound
> rather than CPU bound, and are "fast enough" without much optimization.
That is an excellent point -- our machines (at zappos.com) are memory
bound as well. Now that you mention it, I remember that when I originally
put this optimization in, I was hoping it would result in a memory savings
too, although I never took the time to test it.
Thanks for the reminder :)
Jonathan Field
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Andrew Ho <an...@tellme.com>.
Hello,
JF>Measurable, but also negligable (code below):
JF>
JF>Benchmark: timing 50000 iterations of ref, val...
JF> ref: 3 wallclock secs ( 2.72 usr + 0.12 sys = 2.84 CPU) @ 17605.63/s (n=50000)
JF> val: 7 wallclock secs ( 6.05 usr + 0.18 sys = 6.23 CPU) @ 8025.68/s (n=50000)
So, we use the magic dereference trick in a lot of our code at Tellme,
because it seemed like a good idea not in terms of time performance, but
in saving memory. We have a lot of XML data that we output that can't
always be output a bit at a time... so we end up having big XML strings
that we pass around different handlers. It seems like a good memory
savings to be able to $r->print a reference directly.
I haven't peeked under the hood to see if $r->print just dereferences any
scalar references it gets anyway... in which case the memory savings were
a red herring.
But anyway, just thought I'd comment that the reason I think most mod_perl
developers would think to use that functionality would be memory, rather
than speed. Pretty much all of our mod_perl servers are memory bound
rather than CPU bound, and are "fast enough" without much optimization.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer 1-800-555-TELL Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
----------------------------------------------------------------------
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Jonathan Field <jo...@binadopta.com>.
> My intuition tells me that the performance gain is not mesureable anyway.
Measurable, but also negligable (code below):
Benchmark: timing 50000 iterations of ref, val...
ref: 3 wallclock secs ( 2.72 usr + 0.12 sys = 2.84 CPU) @ 17605.63/s (n=50000)
val: 7 wallclock secs ( 6.05 usr + 0.18 sys = 6.23 CPU) @ 8025.68/s (n=50000)
Since each of our servers is handling less than 20 requests per second
(requests of this type, anyways) we wouldn't gain much with this
optimization. I'm still the type that's always looking for a good
performance tweak, though :) I will look through the performance
guidelines some more, though I think I've already applied them all :)
Thanks for your input!
Jonathan Field
#---------------------------------------
# Benchmark code (hope my logic here is reasonable):
#---------------------------------------
#!/usr/local/bin/perl
use strict;
use warnings;
use Benchmark;
our $string = "a" x 1024 x 100; # simulate a 100KB HTML file
open FILE, ">/dev/null" or die $!; # simulate an very fast connection ;)
our $fh = \*FILE;
timethese(50000, {
'ref' => \&refcpy,
'val' => \&valcpy,
});
sub refcpy {
my $ref = \$string;
print $fh $$ref;
}
sub valcpy {
my $val = $string;
print $fh $val;
}
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Tue, 2 Dec 2003, Jonathan Field wrote:
> I was surprised that the "SCALAR(0x8ca70e4)" output was identical on
> subsequent requests to a child -- indicating to me that the ref (and what
> it was refering to) may have survived the request cycle?
> [snip]
> Just my thoughts as a curious mortal :)
There's an "Ode on a Favourite Cat" that you might like to read...
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Jonathan Field <jo...@binadopta.com>.
> I'm not sure what you mean here.
> Note that *variables* are lexically scoped, but not values.
I was surprised that the "SCALAR(0x8ca70e4)" output was identical on
subsequent requests to a child -- indicating to me that the ref (and what
it was refering to) may have survived the request cycle? I guess would
have expected a different ref, especially after running through the top
part of the handler again, where it reinitializes them. I've included the
code again below for convenience).
Also, the internal magic (switching from PV to PVMG) seems to survive the
request cycle? Regardlesss of whether the $r->print() behavior is going
to be changed, I was surprised that the regex from first request effected
the behavior on the second request.
Just my thoughts as a curious mortal :)
Thanks,
Jonathan
---
sub handler {
my $r = shift;
$r->send_http_header("text/plain");
my $data = "hello\n";
my $dataref = \$data;
# normally we can pass a reference to Apache's print
$r->print($dataref);
$$dataref =~ s/(h)/$1/;
# but not if we've done a successful backreferenced pattern match
$r->print($dataref);
}
1;
On the first request to a given child, I get:
hello
SCALAR(0x8ca70e4)
On subsequent requests I get:
SCALAR(0x8ca70e4)SCALAR(0x8ca70e4)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Jonathan Field wrote:
>
> I am curious why the feature is to be disabled in 2.x? Not questioning
> the judgement, but wondering if it was determined to not be a worthwhile
> performance gain? Or is it just too complex internally despite the gain?
My intuition tells me that the performance gain is not mesureable anyway.
> Also, without any understanding of the internals, it seems to me there may
> be a second problem: on subsequent requests the ref is still hanging
> around (as shown in the original sample output I sent), even though both
> the original scalar and the ref are lexically scoped. One would think
> they had been destroyed by then? Any clue as to what causes that? Is
> this small leak meaningful enough to worry about?
I'm not sure what you mean here.
Note that *variables* are lexically scoped, but not values.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
[OT] RE: [mod_perl] Re: [BUG] Inconsistent $r->print() behavior with references
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
> When I first started working with computers they used to say
> that the cost of the software was roughly equal to the cost
> of the hardware. Now they say that the cost of the hardware
> is roughly zero.
Aw gee - can I have some of that hardware that costs zero please.
Specifically a couple of dual 2GHz G5s with a pair of 23" "Cinema"
displays apiece, and a "big iron" server for my databases.
:-)
Jonathan M. Hollin
Digital-Word Ltd
(http://digital-word.com/)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Tue, 2 Dec 2003, Jonathan Field wrote:
> I am curious why the feature is to be disabled in 2.x? Not questioning
> the judgement, but wondering if it was determined to not be a worthwhile
> performance gain?
I'm sure the performance impact is negligible. If you're looking for
performance, there's a whole section in the Guide for you to read and
you can buy performance much more cheaply from hardware than software.
When I first started working with computers they used to say that the
cost of the software was roughly equal to the cost of the hardware.
Now they say that the cost of the hardware is roughly zero.
Showing my age again. :)
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Jonathan Field <jo...@binadopta.com>.
If I may follow up --
I am curious why the feature is to be disabled in 2.x? Not questioning
the judgement, but wondering if it was determined to not be a worthwhile
performance gain? Or is it just too complex internally despite the gain?
I am always looking to squeeze the last bit of performace out of my
servers, and thought this was a cool little trick :)
Also, without any understanding of the internals, it seems to me there may
be a second problem: on subsequent requests the ref is still hanging
around (as shown in the original sample output I sent), even though both
the original scalar and the ref are lexically scoped. One would think
they had been destroyed by then? Any clue as to what causes that? Is
this small leak meaningful enough to worry about?
In the meantime I'll prepare to stop using this feature! Unless of course
you end up fixing it :)
Thanks,
Jonathan Field
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Ged Haywood wrote:
> I was talking about fixing a fault which is partly the result of a
> daft and deprecated feature which has caused confusion in the past.
Is it documented to be deprecated ? does it issue a deprecation warning ?
(ideally when warnings 'deprecated' is on with perl 5.6 or higher)
> I don't agree that one should be extra
> careful just when he's fixing obscure bugs... :)
The relative obscurity of the said bug doesn't matter.
The question that should be asked is -- do some people rely on this
bug/feature, even inadvertently ? IMHO it's easy to forget dereferencing
a thing when writing code, esp. when the expected result is obtained.
I would suggest :
1. fix the inconsistency with refs to magic scalars
2. introduce an optional deprecation warning
3. left it deprecated "forever" or at least until this deprecated
behaviour causes a difficult problem to somebody.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Stas Bekman wrote:
> Actually I think the current code has another bug. If you do:
>
> my $x = 1;
> print(\$x);
>
> I'd expect it to print 1 and it won't, because $x is IV and not PV. So I'd
> completely drop any checks for PV, and coerce any reference into PV, like so:
>
> SV *sv = SvROK(ST(i)) ? (SV*)SvRV(ST(i)) : ST(i);
> buffer = SvPV(sv, len);
Fine by me. As long as the changelog lists this change :)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Stas Bekman <st...@stason.org>.
Rafael Garcia-Suarez wrote:
> Stas Bekman wrote:
>
>>But you forget that nobody is going pass SVt_PVBM scalar to print(). Why would
>>they? Do you have a concrete example of someone trying to send a scalar of
>>type > PV to print? Rafael, can you think of such an example?
>
>
> Reference to magic scalars ? (\$1)
> to arrays ? to hashes ? to globs ? to subroutines ?
> to lvalues ? (\substr("foo",1,1))
write_client in mp1 does:
for(i = 1; i <= items - 1; i++) {
SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
(SV*)SvRV(ST(i)) : ST(i);
buffer = SvPV(sv, len);
... print buffer ...
}
If you pass any of the above suggested entries to the current code (before the
change) it'll print the ref value (i.e. you won't pass any of these values).
If we change the code to be >= SVt_PV it still won't work, so I can't see what
could this change break.
>>May be to be on the safe side we should check >= SVt_PV and SvPVOK?
>
>
> Yes. SvPOK, even :)
oops, right. I think coercing with SvPV(sv, len) is just fine.
Actually I think the current code has another bug. If you do:
my $x = 1;
print(\$x);
I'd expect it to print 1 and it won't, because $x is IV and not PV. So I'd
completely drop any checks for PV, and coerce any reference into PV, like so:
SV *sv = SvROK(ST(i)) ? (SV*)SvRV(ST(i)) : ST(i);
buffer = SvPV(sv, len);
> (please everyone note that I haven't tested that my suggested change
> even compiles, not mentioning writing regression tests and such :)
chuckle, mp1 has a very limited test suite...
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Stas Bekman wrote:
>
> But you forget that nobody is going pass SVt_PVBM scalar to print(). Why would
> they? Do you have a concrete example of someone trying to send a scalar of
> type > PV to print? Rafael, can you think of such an example?
Reference to magic scalars ? (\$1)
to arrays ? to hashes ? to globs ? to subroutines ?
to lvalues ? (\substr("foo",1,1))
> May be to be on the safe side we should check >= SVt_PV and SvPVOK?
Yes. SvPOK, even :)
(please everyone note that I haven't tested that my suggested change
even compiles, not mentioning writing regression tests and such :)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Let's do this: try to fix it in the next version. If someone discovers
>>that we broke their code we will revert it. How does it sound?
>
>
> well, of course - we wouldn't leave broken code laying around just for fun.
>
> the issue really is how important you think it is to be stable, and exactly
> what that means. to me, this means you dont' introduce changes you aren't
> very sure about. as I said in an earlier post, I am personally very unsure
> about whether allowing all those PV variants is a good idea, simply because
> I have no idea how every one of them is generated, or whether it is
> reasonable to assume that dereferencing _every_ variant results in a
> printable scalar.
>
> if you (or rafael or anybody) is more comfortable with all the ramifications
> because you understand it more completely than I do, just say so - it's no
> big deal, lots of people know more than I do. that's the benefit of open
> source, after all - more people bring more experiences, perspectives, and
> knowledge to the table.
OK, let's ask Rafael and put all the blame on him ;)
I wonder where gozer is hiding.
The real issue is this: Perl always upgrades variables to a higher type as
needed. It never downgrades them. So if the variable was an IV (integer), then
became an NV (float), it'll never go back to IV even if you assign an integer
to it. So I thought that there could be situations we should be worried about.
But let's look of what a user can do:
1. pass an IV/NV/PV scalar to be printed - we coerce it to PV and print.
2. pass a reference to a scalar - we coerce it to PV and print.
if user passes a reference to something unprintable, it's their problem. Most
people won't pass a reference to print, those who do, know what their are doing.
So I think we are safe to apply this fix. If I'm wrong. Well, we will fix it.
The real reason we (current developers) don't want to mess with mp1 is that we
are too busy with mp2. If people with time and knowledge can actively maintain
mp1 I see no reason why shouldn't it be actively developed.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Let's do this: try to fix it in the next version. If someone discovers
> that we broke their code we will revert it. How does it sound?
well, of course - we wouldn't leave broken code laying around just for fun.
the issue really is how important you think it is to be stable, and exactly
what that means. to me, this means you dont' introduce changes you aren't
very sure about. as I said in an earlier post, I am personally very unsure
about whether allowing all those PV variants is a good idea, simply because
I have no idea how every one of them is generated, or whether it is
reasonable to assume that dereferencing _every_ variant results in a
printable scalar.
if you (or rafael or anybody) is more comfortable with all the ramifications
because you understand it more completely than I do, just say so - it's no
big deal, lots of people know more than I do. that's the benefit of open
source, after all - more people bring more experiences, perspectives, and
knowledge to the table.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Stas Bekman <st...@stason.org>.
Frank Maas wrote:
>>Let's do this: try to fix it in the next version. If someone
>>discovers that we broke their code we will revert it. How does it
>>sound?
>
>
> Gee... not on a technical, but more on a philosophical side: is this
> a wise thing to do? It means that you have to be damm sure that someone
> (a) can find out in time that the code is broken and (b) immediately (or
> at least rather soonish) knows that it is broken by this intervention.
Gee, since when philosophy started to block the progress?
Live services aren't supposed to upgrade to a new version of any software
before it has been tested on their staging machines. If someone does and
something goes wrong, too bad for them.
If someone does the testing on their staging/dev machine and learns that we
broke their code, we go and fix it, releasing a new version. I see no problem
with that approach. It's not like mod_perl gets its releases once a year, as
it used to be. On the opposite, with the stable mod_perl 1.0 we saw many more
recent releases.
Don't forget that we have a non-deprecated feature that someone relies on and
it's buggy, we have a solution, which we think is good (at least I think so).
Why should that user suffer?
If you don't pass a scalar reference to print() this change doesn't affect
you. So it certaintly won't affect most of the people, doing plain print.
Now, unless someone wants to contribute a technical reasoning for not
committing Rafael's patch, let's move on and not get into a long philosophy
thread. We have a way too many bugs and missing features that require our
attention, and too few hands willing to do real work.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
RE: [BUG] Inconsistent $r->print() behavior with references
Posted by Frank Maas <fr...@cheiron-it.nl>.
> Let's do this: try to fix it in the next version. If someone
> discovers that we broke their code we will revert it. How does it
> sound?
Gee... not on a technical, but more on a philosophical side: is this
a wise thing to do? It means that you have to be damm sure that someone
(a) can find out in time that the code is broken and (b) immediately (or
at least rather soonish) knows that it is broken by this intervention.
Wouldn't this merit at least a logmessage that tells you that you have
been hit by this?
--Frank
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[..]
>> - SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV);
>> + SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV);
>>
>>+1 to fix this bug.
[...]
>>>but do you really want to derefernce a SVt_PVFM? the implications
>>
>>here are
>>
>>>far beyond my reach.
>>
>>formats don't work with mod_perl anyway, unless you use SFIO. So it's
>>probably irrelevant.
>>http://perl.apache.org/docs/1.0/guide/porting.html#Using_format___and_write__
>
>
> format was just an example - using the above will dereference everything
> from SVt_PVBM to SVt_PVIO. it just sounds like an awful lot of stuff to me
> to be adding where we weren't before (11 more PV variants, according to the
> crack-pipe book), which drastically increases our exposure to unknown behaviors.
But you forget that nobody is going pass SVt_PVBM scalar to print(). Why would
they? Do you have a concrete example of someone trying to send a scalar of
type > PV to print? Rafael, can you think of such an example?
May be to be on the safe side we should check >= SVt_PV and SvPVOK?
> but if the change fixes the bug and you're comfortable with it I'll put it in.
Let's do this: try to fix it in the next version. If someone discovers that we
broke their code we will revert it. How does it sound?
>>Ideally, the deprecation cycle goes as follows:
>>
>>1) leave the current generation of the product as is.
>>2) deprecate the feauture in the next generation.
>>3) remove it only in the 3rd generation.
>
> that's a bit over-zealous as far as I'm concerned - there's no reason we
> couldn't phase out the feature in the 1.0 tree over time. but with 2.0
> reaching fruition, I see no reason to remove any features from 1.0, as the
> migration to 2.0 will be painful enough without a series of mini-migrations
> along the way.
It'd be an ill idea to remove features in mp1. If someone who heavily relying
on a feature and has to stay with mp1 and needs to use the latter versions, to
get some other fixes, you put them in trouble. Sure they "could" go and fix
their code, but why should they? To them it'll be you purposely breaking their
code.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Rafael Garcia-Suarez suggested to:
>
> - SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV);
> + SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV);
>
> +1 to fix this bug.
>
> Jonathan, have you verified that it fixes your problem?
>
> Geoffrey Young then said:
>
>> but do you really want to derefernce a SVt_PVFM? the implications
> here are
>> far beyond my reach.
>
> formats don't work with mod_perl anyway, unless you use SFIO. So it's
> probably irrelevant.
> http://perl.apache.org/docs/1.0/guide/porting.html#Using_format___and_write__
format was just an example - using the above will dereference everything
from SVt_PVBM to SVt_PVIO. it just sounds like an awful lot of stuff to me
to be adding where we weren't before (11 more PV variants, according to the
crack-pipe book), which drastically increases our exposure to unknown behaviors.
but if the change fixes the bug and you're comfortable with it I'll put it in.
> Ideally, the deprecation cycle goes as follows:
>
> 1) leave the current generation of the product as is.
> 2) deprecate the feauture in the next generation.
> 3) remove it only in the 3rd generation.
that's a bit over-zealous as far as I'm concerned - there's no reason we
couldn't phase out the feature in the 1.0 tree over time. but with 2.0
reaching fruition, I see no reason to remove any features from 1.0, as the
migration to 2.0 will be painful enough without a series of mini-migrations
along the way.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Jonathan Field <jo...@binadopta.com>.
Thanks, all, for the prompt attention. I will update my coding habits
accordingly :)
Cheers
On Wed, 10 Dec 2003, Stas Bekman wrote:
> I've pinged Doug and the final verdict is this:
>
> The print-a-scalar-reference feature is now deprecated. There are
> known bugs when using it and it's not supported by mod_perl 2.0. If
> you have a scalar reference containing a string to be printed,
> dereference it before sending it to print.
>
> It's now documented as such.
>
> Jonathan, please adjust your code to dereference the scalar references before
> sending them to print.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Stas Bekman <st...@stason.org>.
I've pinged Doug and the final verdict is this:
The print-a-scalar-reference feature is now deprecated. There are
known bugs when using it and it's not supported by mod_perl 2.0. If
you have a scalar reference containing a string to be printed,
dereference it before sending it to print.
It's now documented as such.
Jonathan, please adjust your code to dereference the scalar references before
sending them to print.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Jonathan Field <jo...@binadopta.com>.
> Rafael Garcia-Suarez suggested to:
>
> - SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV);
> + SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV);
>
> Jonathan, have you verified that it fixes your problem?
Yes. I just tried this change with Apache/1.3.27 (Unix) mod_perl/1.27
mod_ssl/2.8.12 OpenSSL/0.9.6g and it worked like a charm.
> Geoffry Young said:
>
> it just sounds like an awful lot of stuff to me to be adding where we
> weren't before (11 more PV variants, according to the crack-pipe book),
> which drastically increases our exposure to unknown behaviors.
That is true... but I remember the following at some point early on in
the discussion:
> Rafael Garcia-Suarez said:
>
> That's a common idiom in the perl core -- hence my "at first sight".
> A couple of bugs were fixed like this.
I am not able to verify that, but if it is a common thing, perhaps it's
the "right" way to detect a perl scalar reference from the other side?
Not that I understand anything about the other side anyways :)
Cheers,
Jonathan Field
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Stas Bekman <st...@stason.org>.
Rafael Garcia-Suarez suggested to:
- SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV);
+ SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV);
+1 to fix this bug.
Jonathan, have you verified that it fixes your problem?
Geoffrey Young then said:
> but do you really want to derefernce a SVt_PVFM? the implications here are
> far beyond my reach.
formats don't work with mod_perl anyway, unless you use SFIO. So it's probably
irrelevant.
http://perl.apache.org/docs/1.0/guide/porting.html#Using_format___and_write__
Ruslan U. Zakirov wrote:
> IMHO It's better to use complex solution: fix bug reported by Rafael +
> warning about
> deprecation in logs when refs are used with print. Then after two or
> three releases make it obsolete at all.
-1. You can't do that. You can't remove features in the same generation of the
product, therefore mp1 will have this feature forever. We can suggest in the
docs, that it's better to avoid using it, since it's not in the mp2 API.
Ideally, the deprecation cycle goes as follows:
1) leave the current generation of the product as is.
2) deprecate the feauture in the next generation.
3) remove it only in the 3rd generation.
Since we have only two generations, we have no choice but to collapse 1 and 2.
> Also if mp2 already don't allow such magic then this feature have to be
> marked deprecated for more
> compatibility and to keep people from using it, especially those who
> haven't look at mp2 yet(like me).
+1.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by "Ruslan U. Zakirov" <cu...@wildgate.miee.ru>.
Geoffrey Young wrote:
>Ged Haywood wrote:
>
>
>>Shouldn't we in fact be changing something?
>>
>>My view would be that the dereferencing facility should be removed
>>from the standard build but left as a non-default compilation option
>>for those that need it to support old code. A message to STDERR to
>>the effect that the automatic dereferencing is not supported should
>>be enough to prevent confusion in the event that a reference were
>>accidentally passed to the print routine. It could even mention
>>this, er, newly discovered feature. :)
>>
>>
>
>the danger here is changing the stable tree willy nilly. lots of people
>depend on mod_perl running exactly the way it does - every change we toss in
>going forward has the potential for having unforseen consequences and
>costing shops lots of money investigating new issues.
>
>I'm all for fixing bugs. however, if the bug is rare or obscure and can be
>easily worked around, or if it is the result of using a deprecated feature,
>I'm a little hesitant to alter the core at all. not entirely hesitant, mind
>you, but I feel as though we are required to be extra careful.
>
>so, with that in mind, I'd be far more likely to implement a simple change
>that fixed the broken "feature" (perhaps as rafael suggested) than to add
>lots of code that spits out new warnings or otherwise intentionally breaks
>running production code and forces shops to retrofit their codebase.
>
>--Geoff
>
Hello.
IMHO It's better to use complex solution: fix bug reported by Rafael +
warning about
deprecation in logs when refs are used with print. Then after two or
three releases make it obsolete at all.
Also if mp2 already don't allow such magic then this feature have to be
marked deprecated for more
compatibility and to keep people from using it, especially those who
haven't look at mp2 yet(like me).
Best regards. Ruslan.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi Geoff,
On Tue, 2 Dec 2003, Geoffrey Young wrote:
> the danger here is changing the stable tree willy nilly.
I was talking about fixing a fault which is partly the result of a
daft and deprecated feature which has caused confusion in the past.
Of course I thoroughly agree that changes to the stable tree must be
made with the utmost caution and I make no suggestion willy-nilly.
> if the bug is rare or obscure...
> I feel as though we are required to be extra careful.
Agreed that extra careful. I don't agree that one should be extra
careful just when he's fixing obscure bugs... :)
> I'd be far more likely to implement a simple change that fixed the
> broken "feature" (perhaps as rafael suggested) than to add lots of
> code that spits out new warnings
I'm not at all convinced of the simplicity of the proposed change. It
seems to me that (sorry to mix languages in my pseudocode like this :)
#ifndef SUPPORT_AUTOMATIC_SCALAR_DEREFERENCE
if(ref($variable)) {die "Dereference not supported see Changelog 2003-12-25";}
#endif
kills the bug; brings it to the attention of everyone who needs to
know about it; is about as simple as it gets; and has minimum risk
of unforseen consequences. Of course I'd still want it tested.
> or otherwise intentionally breaks running production code and forces
> shops to retrofit their codebase.
Exactly why I suggested a compile-time option to support old code.
I wouldn't dream of forcing shops to fix code which wasn't broken,
although if it *is* broken I don't see any harm in pointing it out
with the appropriate, er, deference.
Incidentally as I understand it, the auto-dereference thing never
was intended to support anything but scalar references, which is
why it always seemed strange to me and I never used it.
Heck, this is probably on the wrong List again... :)
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Ged Haywood wrote:
> Hi all,
>
> On Tue, 2 Dec 2003, Geoffrey Young wrote:
>
>
>>it's fun to track this kind of stuff down, even
>>if we end up not changing anything :)
>
>
> Shouldn't we in fact be changing something?
>
> My view would be that the dereferencing facility should be removed
> from the standard build but left as a non-default compilation option
> for those that need it to support old code. A message to STDERR to
> the effect that the automatic dereferencing is not supported should
> be enough to prevent confusion in the event that a reference were
> accidentally passed to the print routine. It could even mention
> this, er, newly discovered feature. :)
the danger here is changing the stable tree willy nilly. lots of people
depend on mod_perl running exactly the way it does - every change we toss in
going forward has the potential for having unforseen consequences and
costing shops lots of money investigating new issues.
I'm all for fixing bugs. however, if the bug is rare or obscure and can be
easily worked around, or if it is the result of using a deprecated feature,
I'm a little hesitant to alter the core at all. not entirely hesitant, mind
you, but I feel as though we are required to be extra careful.
so, with that in mind, I'd be far more likely to implement a simple change
that fixed the broken "feature" (perhaps as rafael suggested) than to add
lots of code that spits out new warnings or otherwise intentionally breaks
running production code and forces shops to retrofit their codebase.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Stas Bekman <st...@stason.org>.
Ged Haywood wrote:
Ged, please don't do that again. Imagine others starting to post this kind of
requests here. We ask people not to post general perl questions here and you
post a hardware sales request... That's just plain impolite to people.
> ------------------------------------------------------------------------
> [OT] Sorry for this way off-topic part of my post.
>
> We're looking for a Compaq Proliant DL380 G1 server in working order.
> They're getting pretty old now and they're not very common over on
> this side of the Atlantic, but from what I can see on eBay they're
> readily available in the USA, the going rate seems to be about 400-500
> US Dollars. Unfortunately most eBay sellers won't ship internationally.
>
> We're not fussy about the specifications of the machine, it will only
> be used to bench-test new hardware which has to be installed in our
> CoLo, but we'd want it to have a full complement of power supplies and
> obviously the more bang we can get for the bucks the better.
>
> If anyone has one of these machines available for sale, or knows of
> someone with one they'd like to sell, please let me know. We don't
> need any software with it, we'll only be running Linux on it and we
> have all the necessary Compaq software. There's no great hurry, but
> if we could get something in December that would be great.
>
> Alternatively some kind soul might allow me to get a machine delivered
> from eBay to their USA address, then we could get a carrier to collect
> it and bring it to England. That might make people nervous about the
> liability in case of damage or non-delivery: don't worry, I will bear
> the risk. Also, obviously, we wouldn't want anyone to incur any kind
> of expense on our behalf.
> ------------------------------------------------------------------------
>
>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi all,
On Tue, 2 Dec 2003, Geoffrey Young wrote:
> it's fun to track this kind of stuff down, even
> if we end up not changing anything :)
Shouldn't we in fact be changing something?
My view would be that the dereferencing facility should be removed
from the standard build but left as a non-default compilation option
for those that need it to support old code. A message to STDERR to
the effect that the automatic dereferencing is not supported should
be enough to prevent confusion in the event that a reference were
accidentally passed to the print routine. It could even mention
this, er, newly discovered feature. :)
73,
Ged.
PS:
------------------------------------------------------------------------
[OT] Sorry for this way off-topic part of my post.
We're looking for a Compaq Proliant DL380 G1 server in working order.
They're getting pretty old now and they're not very common over on
this side of the Atlantic, but from what I can see on eBay they're
readily available in the USA, the going rate seems to be about 400-500
US Dollars. Unfortunately most eBay sellers won't ship internationally.
We're not fussy about the specifications of the machine, it will only
be used to bench-test new hardware which has to be installed in our
CoLo, but we'd want it to have a full complement of power supplies and
obviously the more bang we can get for the bucks the better.
If anyone has one of these machines available for sale, or knows of
someone with one they'd like to sell, please let me know. We don't
need any software with it, we'll only be running Linux on it and we
have all the necessary Compaq software. There's no great hurry, but
if we could get something in December that would be great.
Alternatively some kind soul might allow me to get a machine delivered
from eBay to their USA address, then we could get a carrier to collect
it and bring it to England. That might make people nervous about the
liability in case of damage or non-delivery: don't worry, I will bear
the risk. Also, obviously, we wouldn't want anyone to incur any kind
of expense on our behalf.
------------------------------------------------------------------------
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [BUG] Inconsistent $r->print() behavior with references
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Jonathan Field wrote:
> Hi all,
>
> This is my first mod_perl bug report, so I'd like to start by thanking you
> all for your great work over the years.
>
> The problem I am experiencing involves passing a scalar reference (instead
> of a scalar) to $r->print(). It usually works as documented. However I
> have come across a situation where instead of printing the contents, it
> prints the string version of the ref itself: "SCALAR(0x8ca70e4)".
>
> After some research, it seems that I can trigger this behavior by doing a
> certain type of regex on the scalar reference, specifically: a successful
> regex that includes a backreference.
> my $data = "hello\n";
> my $dataref = \$data;
> $$dataref =~ s/(h)/$1/;
interesting.
I think the issue is that after your manipulations $dataref is no longer a
plain PV. I used Devel::Peek to look at $dataref before and after and it
changes from a PV to PVMG. where this trips up mod_perl is in
Apache::write_client:
SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
(SV*)SvRV(ST(i)) : ST(i);
so, if the scalar reference to be printed isn't of type SVt_PV it does not
get dereferenced.
I suppose we could change that to a SvPOK check instead, but I'm really not
inclined to change anything here - doug has said several times that the
magical dereferencing in $r->print() was a bad idea and should be considered
deprecated. it's not in 2.0 either, so you'll need to dereference yourself
in order to port your code (someday :)
but thanks for the report - it's fun to track this kind of stuff down, even
if we end up not changing anything :)
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html