You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2004/07/05 13:24:01 UTC
Error with t\api\slurp_filename + t\filter\in_error?
Further to my "Problem running "nmake test" on Win32" posting (sorry I
can't "Reply", but I never received the message back from the list -- I
may have got unsubscribed AGAIN!) I have now reduced the failure to the
following (with the aid of t/SMOKE):
This works:
perl t/TEST -v t\filter\in_error.t t\filter\in_init_basic.t
and this works:
perl t/TEST -v t\api\slurp_filename.t
but this fails:
perl t/TEST -v t\api\slurp_filename.t t\filter\in_error.t
t\filter\in_init_basic.t
The Apache server dies after in_error, so in_init_basic fails to connect:
t\api\slurp_filename......1..5
# Running under perl version 5.008004 for MSWin32
# Current time local: Mon Jul 5 12:19:30 2004
# Current time GMT: Mon Jul 5 11:19:30 2004
# Using Test.pm version 1.24
# testing : slurp filename untainted
# received: English: Internet
# Hebrew : ÎÉÎÖÎáÎÿοÎáÎÿ
# expected: English: Internet
# Hebrew : ÎÉÎÖÎáÎÿοÎáÎÿ
ok 1
# testing : slurp filename tainted
# received: Insecure dependency in eval while running with -T switch at
C:\Temp\modperl-2.0\t\response/TestAPI/slurp_filename.pm line 36.
# expected: (?-xism:Insecure dependency in eval)
ok 2
# testing : slurp filename untainted
# received: English: Internet
# Hebrew : ÎÉÎÖÎáÎÿοÎáÎÿ
# expected: English: Internet
# Hebrew : ÎÉÎÖÎáÎÿοÎáÎÿ
ok 3
# testing : slurp filename (perl) tainted
# received: Insecure dependency in eval while running with -T switch at
C:\Temp\modperl-2.0\t\response/TestAPI/slurp_filename.pm line 50.
# expected: (?-xism:Insecure dependency in eval)
ok 4
# testing : slurp filename (perl) untainted
# received: English: Internet
# Hebrew : ÎÉÎÖÎáÎÿοÎáÎÿ
# expected: English: Internet
# Hebrew : ÎÉÎÖÎáÎÿοÎáÎÿ
ok 5
ok
t\filter\in_error.........1..1
# Running under perl version 5.008004 for MSWin32
# Current time local: Mon Jul 5 12:19:51 2004
# Current time GMT: Mon Jul 5 11:19:51 2004
# Using Test.pm version 1.24
# testing : an error in a filter should cause 500
# received: 500
# expected: 500
ok 1
ok
t\filter\in_init_basic....1..1
# Running under perl version 5.008004 for MSWin32
# Current time local: Mon Jul 5 12:19:53 2004
# Current time GMT: Mon Jul 5 11:19:53 2004
# Using Test.pm version 1.24
# Failed test 1 in t\filter\in_init_basic.t at line 16
# testing : test filter init functionality
# received: 500 Can't connect to localhost:8529 (connect: Unknown error)
# expected: (?-xism:content ok
# init 1
# run [12]
# )
not ok 1
FAILED test 1
Looks like the "error in a filter" that "should cause 500" actually
causes a server crash rather than a 500 (but only after running the
slurp_filename test!)
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: Error with t\api\slurp_filename + t\filter\in_error?
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
>
>> I can reproduce this with prefork, running:
>> t/TEST -minclients 1 t/api/slurp_filename.t t/filter/in_error.t
>
>
> It's now self contained, after I've moved the -T problem eval into
> in_error itself:
>
> Index: t/filter/TestFilter/in_error.pm
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/in_error.pm,v
> retrieving revision 1.3
> diff -u -r1.3 in_error.pm
> --- t/filter/TestFilter/in_error.pm 31 Dec 2003 19:07:26 -0000 1.3
> +++ t/filter/TestFilter/in_error.pm 8 Jul 2004 00:28:50 -0000
> @@ -23,7 +23,6 @@
>
> debug join '', "-" x 20 , " filter called ", "-" x 20;
>
> - t_server_log_error_is_expected();
> die "This filter must die";
>
> return Apache::OK;
> @@ -32,10 +31,14 @@
> sub response {
> my $r = shift;
>
> + # cause taint problems, as there was a bug (panic: POPSTACK)
> + # caused when APR/Error.pm was attempted to be loaded from
> + # $r->read() when the latter was trying to croak about the failed
> + # read, due to the filter returning 500
> + eval { system('echo', 'hello') };
> +
> + t_server_log_error_is_expected(2);
> my $len = $r->read(my $data, $r->headers_in->{'Content-Length'});
> - t_server_log_error_is_expected();
> - die "failed to read POSTed data: $!" unless defined $len;
> - debug "read $len bytes [$data]";
>
> $r->content_type('text/plain');
> $r->print("it shouldn't be printed, because the input filter has
> died");
>
> I couldn't quite figure out where the wrecked OP stack problem comes
> from (the panic message comes from POPSTACK macro in cop.h), but
> breaking in that code with gdb, showed that the problem was caused by
> trying to require APR/Error.pm.
in fact the problem happens when trying to load any file, or any perl
code that calls POPSTACK internally, which is the case with
Perl_load_module.
> Ideally APR/Error.pm should be loaded at the server startup, but I can't
> figure out where to do that, since Apache2.pm could be loaded anywhere
> in the startup phase and we may need that module even before Apache2 is
> loaded...
I'm still not sure how the best to deal with it, so I've committed a
temporary solution, which loads APR::Error at the server startup.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Error with t\api\slurp_filename + t\filter\in_error?
Posted by Stas Bekman <st...@stason.org>.
> I can reproduce this with prefork, running:
> t/TEST -minclients 1 t/api/slurp_filename.t t/filter/in_error.t
It's now self contained, after I've moved the -T problem eval into
in_error itself:
Index: t/filter/TestFilter/in_error.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/in_error.pm,v
retrieving revision 1.3
diff -u -r1.3 in_error.pm
--- t/filter/TestFilter/in_error.pm 31 Dec 2003 19:07:26 -0000 1.3
+++ t/filter/TestFilter/in_error.pm 8 Jul 2004 00:28:50 -0000
@@ -23,7 +23,6 @@
debug join '', "-" x 20 , " filter called ", "-" x 20;
- t_server_log_error_is_expected();
die "This filter must die";
return Apache::OK;
@@ -32,10 +31,14 @@
sub response {
my $r = shift;
+ # cause taint problems, as there was a bug (panic: POPSTACK)
+ # caused when APR/Error.pm was attempted to be loaded from
+ # $r->read() when the latter was trying to croak about the failed
+ # read, due to the filter returning 500
+ eval { system('echo', 'hello') };
+
+ t_server_log_error_is_expected(2);
my $len = $r->read(my $data, $r->headers_in->{'Content-Length'});
- t_server_log_error_is_expected();
- die "failed to read POSTed data: $!" unless defined $len;
- debug "read $len bytes [$data]";
$r->content_type('text/plain');
$r->print("it shouldn't be printed, because the input filter has
died");
I couldn't quite figure out where the wrecked OP stack problem comes
from (the panic message comes from POPSTACK macro in cop.h), but
breaking in that code with gdb, showed that the problem was caused by
trying to require APR/Error.pm.
Ideally APR/Error.pm should be loaded at the server startup, but I can't
figure out where to do that, since Apache2.pm could be loaded anywhere
in the startup phase and we may need that module even before Apache2 is
loaded...
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Error with t\api\slurp_filename + t\filter\in_error?
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
> Further to this, I tried starting the server from the
> command line in one window, and then running the tests in
> another as
> perl t/TEST --no-httpd t\api\slurp_filename.t t\filter\in_error.t
> All tests were successful, but immediately after, the
> following appeared in the error log:
>
> *** The following error entry is expected and harmless ***
> [...] This filter must die at ... in_error.pm line 27
> panic: POPSTACK
> Callback called exit.
> [...] Parent: child process exited with status 255 -- Restarting
>
> The server then restarts itself.
>
> So this sounds like an error from Perl - I don't have a
> Perl built with debugging; I'll try this weekend to do so.
I can reproduce this with prefork, running:
t/TEST -minclients 1 t/api/slurp_filename.t t/filter/in_error.t
Looking into it.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Error with t\api\slurp_filename + t\filter\in_error?
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 6 Jul 2004, Randy Kobes wrote:
> On Tue, 6 Jul 2004, Stas Bekman wrote:
>
> > Randy Kobes wrote:
> > > On Mon, 5 Jul 2004, Steve Hay wrote:
> [ ... ]
> > >>but this fails:perl t/TEST -v
> > >>t\api\slurp_filename.t t\filter\in_error.t t\filter\in_init_basic.t
> > >
> > >>The Apache server dies after in_error, so in_init_basic
> > >>fails to connect:
Further to this, I tried starting the server from the
command line in one window, and then running the tests in
another as
perl t/TEST --no-httpd t\api\slurp_filename.t t\filter\in_error.t
All tests were successful, but immediately after, the
following appeared in the error log:
*** The following error entry is expected and harmless ***
[...] This filter must die at ... in_error.pm line 27
panic: POPSTACK
Callback called exit.
[...] Parent: child process exited with status 255 -- Restarting
The server then restarts itself.
So this sounds like an error from Perl - I don't have a
Perl built with debugging; I'll try this weekend to do so.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Error with t\api\slurp_filename + t\filter\in_error?
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 6 Jul 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Mon, 5 Jul 2004, Steve Hay wrote:
[ ... ]
> >>but this fails:perl t/TEST -v
> >>t\api\slurp_filename.t t\filter\in_error.t t\filter\in_init_basic.t
> >
> >>The Apache server dies after in_error, so in_init_basic
> >>fails to connect:
> >
> > I think this has something to do with tainting - reducing
> > slurp_filename.pm to (using non-utf8 data, to eliminate
> > one possibility):
[ ... ]
> > then the sequence Steve mentioned for the disconnect
> > occurs, but changing to
> > my $data = $r->slurp_filename(0);
> > causes no such problem.
>
> So does the worker really crash as Steve has suggested?
Not really a crash (no annoying popup windows appear,
nor is anything in the error log) - the server just goes
away ....
> Can you add something after the eval test above and see
> whether it still gets executed/printed/sent to the client?
>
> Does it have anything to do with the nested eval?
>
> eval {$received = eval $$data};
>
> Can you use any different approach to cause a taint error
> (e.g. qx[ls $data]) or something? Does the problem
> persist?
I tried this:
=========================================================
package TestAPI::slurp_filename;
[ ... ]
sub handler {
my $r = shift;
plan $r, tests => 1;
{
eval { system('echo', 'hello') };
# my ($a, $b) = (1, 0);
# eval {my $ans = $a / $b};
ok t_cmp($@, qr/Insecure|Illegal/, "just testing");
}
Apache::OK;
}
[ ... ]
=============================================================
and this also led to the server going away (here, the
taint error is an insecure $ENV{PATH}). And, just to
check to see if it was due to the setting of $@ from
eval{}, I commented out the
eval { system('echo', 'hello') };
and enabled
# my ($a, $b) = (1, 0);
# eval {my $ans = $a / $b};
but this was OK. So the problem seems specific to a
taint check.
One other tidbit - if in t/filter/TestFilter/in_error.pm,
one uses an "exit", rather than a "die", then the sequence
of tests are OK. I also tried making up a different
intermediate (rather than filter/in_error) test that didn't
involve filters but had a die() in it, but that was still
OK. So the intermediate test involving both a filter and a
die seems relevant ....
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Error with t\api\slurp_filename + t\filter\in_error?
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 5 Jul 2004, Steve Hay wrote:
>
>
>>Further to my "Problem running "nmake test" on Win32"
>>posting (sorry I can't "Reply", but I never received the
>>message back from the list -- I may have got unsubscribed
>>AGAIN!) I have now reduced the failure to the following
>>(with the aid of t/SMOKE):
>>
>>This works:perl t/TEST -v t\filter\in_error.t t\filter\in_init_basic.t
>>
>>and this works:perl t/TEST -v t\api\slurp_filename.t
>>
>>but this fails:perl t/TEST -v
>>t\api\slurp_filename.t t\filter\in_error.t t\filter\in_init_basic.t
>
>
>>The Apache server dies after in_error, so in_init_basic
>>fails to connect:
>
>
> I think this has something to do with tainting - reducing
> slurp_filename.pm to (using non-utf8 data, to eliminate
> one possibility):
> ==========================================================
> package TestAPI::slurp_filename;
> # test with non-utf8 data
> my $expected = <<EOI;
> English: Internet
> Hebrew : Junk
> EOI
>
> sub handler {
> my $r = shift;
>
> plan $r, tests => 1;
>
> {
> my $data = $r->slurp_filename;
> my $received;
> eval {$received = eval $$data};
> ok t_cmp($@, qr/Insecure dependency in eval/, "slurp filename tainted");
> }
>
> Apache::OK;
> }
> # ...
> ================================================================
> then the sequence Steve mentioned for the disconnect
> occurs, but changing to
> my $data = $r->slurp_filename(0);
> causes no such problem.
So does the worker really crash as Steve has suggested?
Can you add something after the eval test above and see whether it still gets
executed/printed/sent to the client?
Does it have anything to do with the nested eval?
eval {$received = eval $$data};
Can you use any different approach to cause a taint error (e.g. qx[ls $data])
or something? Does the problem persist?
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Error with t\api\slurp_filename + t\filter\in_error?
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 5 Jul 2004, Steve Hay wrote:
> Further to my "Problem running "nmake test" on Win32"
> posting (sorry I can't "Reply", but I never received the
> message back from the list -- I may have got unsubscribed
> AGAIN!) I have now reduced the failure to the following
> (with the aid of t/SMOKE):
>
> This works:perl t/TEST -v t\filter\in_error.t t\filter\in_init_basic.t
>
> and this works:perl t/TEST -v t\api\slurp_filename.t
>
> but this fails:perl t/TEST -v
> t\api\slurp_filename.t t\filter\in_error.t t\filter\in_init_basic.t
> The Apache server dies after in_error, so in_init_basic
> fails to connect:
I think this has something to do with tainting - reducing
slurp_filename.pm to (using non-utf8 data, to eliminate
one possibility):
==========================================================
package TestAPI::slurp_filename;
# test with non-utf8 data
my $expected = <<EOI;
English: Internet
Hebrew : Junk
EOI
sub handler {
my $r = shift;
plan $r, tests => 1;
{
my $data = $r->slurp_filename;
my $received;
eval {$received = eval $$data};
ok t_cmp($@, qr/Insecure dependency in eval/, "slurp filename tainted");
}
Apache::OK;
}
# ...
================================================================
then the sequence Steve mentioned for the disconnect
occurs, but changing to
my $data = $r->slurp_filename(0);
causes no such problem.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org