You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Dmitry Karasik <dm...@karasik.eu.org> on 2007/10/01 16:49:57 UTC
[mp2] mod_perl closes apache's stdin and/or stdout
Hello,
As a follow-up to my previous bug report to users@,
( http://www.gossamer-threads.com/lists/modperl/modperl/94912 )
I'd like to re-post the same issue to dev@, because I'm unsure
what is the status of this bugreport, and basically if it
was recognized as one.
Just for the sake if the test wasn't reproduced correctly, I'll rerun:
1) test setup:
add to httpd.conf:
<LocationMatch "^/cgi-bin/m.cgi$">
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
</LocationMatch>
<LocationMatch "^/cgi-bin/a.cgi$">
SetHandler cgi-script
</LocationMatch>
both cgis are identical, and are:
#!/usr/bin/perl -w
print "Content-type: text/html\n\n", $ENV{MOD_PERL}||'', "\n", <STDIN>, "\n";
test.pl:
open F, "|nc localhost 80"; # this requires netcat because I'm lazy
print F <<R;
POST /cgi-bin/m.cgi HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
Keep-Alive: 300
submit=Submit
POST /cgi-bin/a.cgi HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
Keep-Alive: 0
Connection: close
submit=Submit
R
2)
- now, stop apache, run it from console as 'httpd -X' ( or apache2 -X on some linux distros)
- run 'perl test.pl'
The bug manifests itself in that the following apache response is printed out (some lines are skipped):
HTTP/1.1 200 OK
1d
mod_perl/2.0.3
submit=Submit
0
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html
2
0
and the second request doesn't contain 'submit=Submit' line.
This can be fixed by applying the following patch:
--- modperl_io.c.orig 2007-09-25 15:36:02.000000000 +0200
+++ modperl_io.c 2007-09-25 15:35:51.000000000 +0200
@@ -129,6 +129,15 @@
Perl_croak(aTHX_ "Failed to dup STDIN: %" SVf, get_sv("!", TRUE));
}
+ /* In mixed environment of mod_perl and cgi scripts, cgi scripts may read content of
+ * POST requests off STDIN. do_close() calls actual close(0), freeing the descriptor 0
+ * for reuse, and creating havoc for anyone reading from file descriptor 0.
+ * This hack changes the IO type to IoTYPE_STD, because do_close() does not call
+ * underlying close() on IO handles of these types, but does free the associated
+ * resources. */
+ if ( IoIFP(io) && PerlIO_fileno(IoIFP(io)) == 0)
+ IoTYPE(io) = IoTYPE_STD;
+
/* similar to PerlIO::scalar, the PerlIO::Apache layer doesn't
* have file descriptors, so STDIN must be closed before it can
* be reopened */
So, I'm not sure what other information I can provide, please tell me if there's anything
more, because I'd love to see that bug fixed.
--
Sincerely,
Dmitry Karasik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Dmitry Karasik <dm...@karasik.eu.org>.
> Dimitry said the problem occurs only for the very first request after Apache
> has been started. I suspect the first request a newly born Apache child
> handles is affected.
Not only on the first request, that effect also happens on subsequent requests,
but the very first request is also the one that gives an always reproducible
case.
--
Sincerely,
Dmitry Karasik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Torsten Foertsch <to...@gmx.net>.
On Monday 01 October 2007 18:53, Fred Moyer wrote:
> It's really important to show a failing regression test here to prove
> that it fails on your setup, but passes on other users' setups. I
> looked through the thread and it looks like you are using a perlio
> enabled perl, so that's probably not the problem.
Dimitry said the problem occurs only for the very first request after Apache
has been started. I suspect the first request a newly born Apache child
handles is affected.
I think a test for that situation is difficult to write.
Torsten
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Dmitry Karasik <dm...@karasik.eu.org>.
There's one thing, it might be important, and might be not. The 'Alias'
setting didn't work on my setup, so instead of finding what's wrong with Alias,
I changed the config so the setup has two different but identical files perform
mod_perl and cgi requests. So this section was (to be pedantic) different:
> +<IfModule mod_alias.c>
> + Alias /stdin_override/mod_perl @ServerRoot@/cgi-bin/stdin.pl
> + Alias /stdin_override/cgi @ServerRoot@/cgi-bin/stdin.pl
> +</IfModule>
> +
> +<Location /stdin_override/mod_perl>
> + SetHandler perl-script
> + PerlResponseHandler ModPerl::Registry
> + PerlOptions +ParseHeaders
> + Options +ExecCGI
> +</Location>
> +
> +<Location /stdin_override/cgi>
> + SetHandler cgi-script
> + Options +ExecCGI
> +</Location>
Instead it was
+<Location /cgi-bin/stdin_mod_perl.pl>
+ SetHandler perl-script
+ PerlResponseHandler ModPerl::Registry
+ PerlOptions +ParseHeaders
+ Options +ExecCGI
+</Location>
+
+<Location /cgi-bin/stdin_cgi.pl>
+ SetHandler cgi-script
+ Options +ExecCGI
+</Location>
where stdin_cgi.pl and stdin_mod_perl.pl are copies of stdin.pl .
May I ask you to try that altered setup?
> Looking at modperl_io_perlio_restore_stdin however, isn't this where the
> real problem lies? It does restore Perl's stdin handle back to it's original
> state, but I don't see where/how that code would guarantee STDIN to re-acquire
> the same FD. Isn't that the bug ?
The problem is that modperl_io_perlio_restore_stdin() is called much later,
after possibly several further mod_perl requests are executed. I agree that
making sure to reassign FD to 0 (and stdout etc) would be a good idea, however,
by the time when the cgi script in question is being run, the FD 0 would stay
closed disregarding of whether modperl_io_perlio_restore_stdin() does the right
thing or not.
> And avoiding the close() in the sugested patch would still need to undo
> the override in modperl_io_perlio_restore_stdin() to allow the real, underlying
> STDIN to be eventially closed, no ?
I do not understand that need to close FD 0 at all. All the overriding business
is done here so that PerlIO-level STDIN glob would be something else than FD 0,
which is fine. My point is that FD 0 is a shared resource within apache process
space, and it is neither mod_perl nor anyone else's business to close it.
--
Sincerely,
Dmitry Karasik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Dmitry Karasik wrote:
>> Does this test pass for you when you apply the patch in this thread?
>> http://marc.info/?l=apache-modperl&m=119072925228529&w=2
>
> You mean my own patch? Yes, it does pass with the patch applied.
Here is what I am testing with:
Index: ModPerl-Registry/t/stdin.t
===================================================================
--- ModPerl-Registry/t/stdin.t (revision 0)
+++ ModPerl-Registry/t/stdin.t (revision 0)
@@ -0,0 +1,26 @@
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+use Apache::TestRequest qw(POST);
+
+Apache::TestRequest::user_agent(keep_alive => 1);
+
+plan tests => 2, need [qw(CGI)],
+ need_min_module_version CGI => 3.08;
+
+{
+ my $url = "/stdin_override/mod_perl";
+ my $res = POST $url, [submit=>1];
+
+ ok t_cmp($res->content,
+ qr{submitted},
+ "form submission ok under mod_perl");
+
+ $url = "/stdin_override/cgi";
+ $res = POST $url, [submit=>1];
+ ok t_cmp($res->content,
+ qr{submitted},
+ "stdin reset, form submission ok under cgi");
+}
Index: ModPerl-Registry/t/conf/extra.conf.in
===================================================================
--- ModPerl-Registry/t/conf/extra.conf.in (revision 583059)
+++ ModPerl-Registry/t/conf/extra.conf.in (working copy)
@@ -183,6 +183,24 @@
PerlResponseHandler ModPerl::Registry
</Location>
+### test for mixed mod_perl/cgi environment ###
+<IfModule mod_alias.c>
+ Alias /stdin_override/mod_perl @ServerRoot@/cgi-bin/stdin.pl
+ Alias /stdin_override/cgi @ServerRoot@/cgi-bin/stdin.pl
+</IfModule>
+
+<Location /stdin_override/mod_perl>
+ SetHandler perl-script
+ PerlResponseHandler ModPerl::Registry
+ PerlOptions +ParseHeaders
+ Options +ExecCGI
+</Location>
+
+<Location /stdin_override/cgi>
+ SetHandler cgi-script
+ Options +ExecCGI
+</Location>
+
### deflate tests ###
<IfModule mod_alias.c>
Alias /registry_bb_deflate/ @ServerRoot@/cgi-bin/
Index: ModPerl-Registry/t/cgi-bin/stdin.pl
===================================================================
--- ModPerl-Registry/t/cgi-bin/stdin.pl (revision 0)
+++ ModPerl-Registry/t/cgi-bin/stdin.pl (revision 0)
@@ -0,0 +1,18 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use CGI qw/:standard/;
+
+print <<END;
+Content-type: text/plain
+
+END
+
+if (param()) {
+ my $submit = param('submit');
+ if ($submit) {
+ print "submitted";
+ }
+}
$> t/TEST -start-httpd -one-process
$> t/TEST -run-tests -verbose t/stdin.t
[...]
All tests successful.
That's without the IO patch, and I tried with :
Perl-5.8.8 (Redhat Fedora Core 7)
httpd/2.2.2/worker
httpd/2.2.2/prefork
I, for one, suspect there is some important variable we are not narrowing
down on here.
The IO patch itself, which avoids calling close() on the underlying FD, worries
me a little. Are we really fixing the problem, or just dodging it for this
particular case ?
With the patch, I see this test failing:
t/modperl/io_nested_with_cled_stds
I agree with the spirit of the patch. Avoiding the call to close() on
the underlying FD for STDIN makes sure nobody else calling open() could
accidentally grab it. (BTW, shouldn't the same fix be applied to STDOUT
as well?).
Looking at modperl_io_perlio_restore_stdin however, isn't this where the
real problem lies? It does restore Perl's stdin handle back to it's original
state, but I don't see where/how that code would guarantee STDIN to re-acquire
the same FD. Isn't that the bug ?
And avoiding the close() in the sugested patch would still need to undo
the override in modperl_io_perlio_restore_stdin() to allow the real, underlying
STDIN to be eventially closed, no ?
------------------------------------------------------------------------
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Dmitry Karasik <dm...@karasik.eu.org>.
> Does this test pass for you when you apply the patch in this thread?
> http://marc.info/?l=apache-modperl&m=119072925228529&w=2
You mean my own patch? Yes, it does pass with the patch applied.
>
> >/dk
> >
> >
> >
> >My log:
> >
> >$ ./t/TEST -start-httpd -one-process
> >/usr/local/sbin/httpd -D ONE_PROCESS -d
> >/usr/ports/www/mod_perl2/work/mod_perl-2.0.3/ModPerl-Registry/t -f
> >/usr/ports/www/mod_perl2/work/mod_perl-2.0.3/ModPerl-Registry/t/conf/httpd.conf -D APACHE2
> >using Apache/2.2.6 (prefork MPM)
> >
> >waiting 90 seconds for server to start: ...
> >waiting 90 seconds for server to start: ok (waited 2 secs)
> >server localhost:8529 started
> >
> >$ t/TEST -run-tests -verbose t/stdin.t
> >t/stdin....1..2
> ># Running under perl version 5.008008 for freebsd
> ># Current time local: Mon Oct 8 11:05:12 2007
> ># Current time GMT: Mon Oct 8 09:05:12 2007
> ># Using Test.pm version 1.25
> ># Using Apache/Test.pm version 1.29
> ># testing : form submission ok under mod_perl
> ># expected: (?-xism:submitted)
> ># received: submitted / mod_perl/2.0.3
> >ok 1
> ># testing : stdin reset, form submission ok under cgi
> ># expected: (?-xism:submitted)
> ># received:
> >not ok 2
> ># Failed test 2 in t/stdin.t at line 25
> >FAILED test 2
> > Failed 1/2 tests, 50.00% okay
> >Failed Test Stat Wstat Total Fail List of Failed
> >-------------------------------------------------------------------------------
> >t/stdin.t 2 1 2
> >Failed 1/1 test scripts. 1/2 subtests failed.
> >Files=1, Tests=2, 2 wallclock secs ( 0.30 cusr + 0.05 csys = 0.36 CPU)
> >Failed 1/1 test programs. 1/2 subtests failed.
> >[ error] error running tests (please examine t/logs/error_log)
> >[1] 86918 exit 1 t/TEST -run-tests -verbose t/stdin.t
> >
> >
> >
> >
> >
> >On Tue, Oct 02, 2007 at 08:16:20PM +0200, Torsten Foertsch wrote:
> >>On Tuesday 02 October 2007 08:54, Dmitry Karasik wrote:
> >>>>Can you try the updated test patch that Torsten replied to the list
> >>>>with:
> >>>>
> >>>>http://marc.info/?l=apache-modperl&m=119074979901161&w=2
> >>>The test succeeds in boths cases, on both patched and unpatched mod_perl.
> >>>I don't know why is that, but I think that shouldn't be a reason to
> >>>ignore
> >>>the error that is reproduced using the test case I proposed (and
> >>>of course because of the Pesticide Paradox :)
> >>Try the following (assuming you are using prefork):
> >>
> >>0) cd ModPerl-Registry/
> >>1) start the testsuite with t/TEST -start-httpd
> >>2) kill all apache children (workers). The supervisor apache should
> >>respawn new children.
> >>3) Then run your test: t/TEST -run-tests -verbose t/stdin.t
> >>
> >>I hope it fails this way. If yes then maybe a way to construct a proper
> >>test is to add a new vhost with very limited MaxRequestsPerChild (1 or 2)
> >>
> >>Torsten
> >
> >
> >
--
Sincerely,
Dmitry Karasik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
Dmitry Karasik wrote:
> I found the change that triggers the bug with mod_perl tests:
> This line
>
> Apache::TestRequest::user_agent( keep_alive => 1);
>
> added in stdin.t does it. I hope it is convincing enough now. I still don't
> understand why it was so hard to try to reproduce my test setup with netcat.
Does this test pass for you when you apply the patch in this thread?
http://marc.info/?l=apache-modperl&m=119072925228529&w=2
> /dk
>
>
>
> My log:
>
> $ ./t/TEST -start-httpd -one-process
> /usr/local/sbin/httpd -D ONE_PROCESS -d /usr/ports/www/mod_perl2/work/mod_perl-2.0.3/ModPerl-Registry/t -f /usr/ports/www/mod_perl2/work/mod_perl-2.0.3/ModPerl-Registry/t/conf/httpd.conf -D APACHE2
> using Apache/2.2.6 (prefork MPM)
>
> waiting 90 seconds for server to start: ...
> waiting 90 seconds for server to start: ok (waited 2 secs)
> server localhost:8529 started
>
> $ t/TEST -run-tests -verbose t/stdin.t
> t/stdin....1..2
> # Running under perl version 5.008008 for freebsd
> # Current time local: Mon Oct 8 11:05:12 2007
> # Current time GMT: Mon Oct 8 09:05:12 2007
> # Using Test.pm version 1.25
> # Using Apache/Test.pm version 1.29
> # testing : form submission ok under mod_perl
> # expected: (?-xism:submitted)
> # received: submitted / mod_perl/2.0.3
> ok 1
> # testing : stdin reset, form submission ok under cgi
> # expected: (?-xism:submitted)
> # received:
> not ok 2
> # Failed test 2 in t/stdin.t at line 25
> FAILED test 2
> Failed 1/2 tests, 50.00% okay
> Failed Test Stat Wstat Total Fail List of Failed
> -------------------------------------------------------------------------------
> t/stdin.t 2 1 2
> Failed 1/1 test scripts. 1/2 subtests failed.
> Files=1, Tests=2, 2 wallclock secs ( 0.30 cusr + 0.05 csys = 0.36 CPU)
> Failed 1/1 test programs. 1/2 subtests failed.
> [ error] error running tests (please examine t/logs/error_log)
> [1] 86918 exit 1 t/TEST -run-tests -verbose t/stdin.t
>
>
>
>
>
> On Tue, Oct 02, 2007 at 08:16:20PM +0200, Torsten Foertsch wrote:
>> On Tuesday 02 October 2007 08:54, Dmitry Karasik wrote:
>>>> Can you try the updated test patch that Torsten replied to the list with:
>>>>
>>>> http://marc.info/?l=apache-modperl&m=119074979901161&w=2
>>> The test succeeds in boths cases, on both patched and unpatched mod_perl.
>>> I don't know why is that, but I think that shouldn't be a reason to ignore
>>> the error that is reproduced using the test case I proposed (and
>>> of course because of the Pesticide Paradox :)
>> Try the following (assuming you are using prefork):
>>
>> 0) cd ModPerl-Registry/
>> 1) start the testsuite with t/TEST -start-httpd
>> 2) kill all apache children (workers). The supervisor apache should respawn
>> new children.
>> 3) Then run your test: t/TEST -run-tests -verbose t/stdin.t
>>
>> I hope it fails this way. If yes then maybe a way to construct a proper test
>> is to add a new vhost with very limited MaxRequestsPerChild (1 or 2)
>>
>> Torsten
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Dmitry Karasik <dm...@karasik.eu.org>.
I found the change that triggers the bug with mod_perl tests:
This line
Apache::TestRequest::user_agent( keep_alive => 1);
added in stdin.t does it. I hope it is convincing enough now. I still don't
understand why it was so hard to try to reproduce my test setup with netcat.
/dk
My log:
$ ./t/TEST -start-httpd -one-process
/usr/local/sbin/httpd -D ONE_PROCESS -d /usr/ports/www/mod_perl2/work/mod_perl-2.0.3/ModPerl-Registry/t -f /usr/ports/www/mod_perl2/work/mod_perl-2.0.3/ModPerl-Registry/t/conf/httpd.conf -D APACHE2
using Apache/2.2.6 (prefork MPM)
waiting 90 seconds for server to start: ...
waiting 90 seconds for server to start: ok (waited 2 secs)
server localhost:8529 started
$ t/TEST -run-tests -verbose t/stdin.t
t/stdin....1..2
# Running under perl version 5.008008 for freebsd
# Current time local: Mon Oct 8 11:05:12 2007
# Current time GMT: Mon Oct 8 09:05:12 2007
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.29
# testing : form submission ok under mod_perl
# expected: (?-xism:submitted)
# received: submitted / mod_perl/2.0.3
ok 1
# testing : stdin reset, form submission ok under cgi
# expected: (?-xism:submitted)
# received:
not ok 2
# Failed test 2 in t/stdin.t at line 25
FAILED test 2
Failed 1/2 tests, 50.00% okay
Failed Test Stat Wstat Total Fail List of Failed
-------------------------------------------------------------------------------
t/stdin.t 2 1 2
Failed 1/1 test scripts. 1/2 subtests failed.
Files=1, Tests=2, 2 wallclock secs ( 0.30 cusr + 0.05 csys = 0.36 CPU)
Failed 1/1 test programs. 1/2 subtests failed.
[ error] error running tests (please examine t/logs/error_log)
[1] 86918 exit 1 t/TEST -run-tests -verbose t/stdin.t
On Tue, Oct 02, 2007 at 08:16:20PM +0200, Torsten Foertsch wrote:
> On Tuesday 02 October 2007 08:54, Dmitry Karasik wrote:
> > > Can you try the updated test patch that Torsten replied to the list with:
> > >
> > > http://marc.info/?l=apache-modperl&m=119074979901161&w=2
> >
> > The test succeeds in boths cases, on both patched and unpatched mod_perl.
> > I don't know why is that, but I think that shouldn't be a reason to ignore
> > the error that is reproduced using the test case I proposed (and
> > of course because of the Pesticide Paradox :)
>
> Try the following (assuming you are using prefork):
>
> 0) cd ModPerl-Registry/
> 1) start the testsuite with t/TEST -start-httpd
> 2) kill all apache children (workers). The supervisor apache should respawn
> new children.
> 3) Then run your test: t/TEST -run-tests -verbose t/stdin.t
>
> I hope it fails this way. If yes then maybe a way to construct a proper test
> is to add a new vhost with very limited MaxRequestsPerChild (1 or 2)
>
> Torsten
--
Sincerely,
Dmitry Karasik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Dmitry Karasik <dm...@karasik.eu.org>.
>
> have you tried
>
> $ t/TEST -one-process t/yourtest.t
same result, the bug does not show.
--
Sincerely,
Dmitry Karasik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Dmitry Karasik wrote:
>> 0) cd ModPerl-Registry/
>> 1) start the testsuite with t/TEST -start-httpd
>> 2) kill all apache children (workers). The supervisor apache should respawn
>> new children.
>> 3) Then run your test: t/TEST -run-tests -verbose t/stdin.t
>
> No, it doesn't, it passes. I tried both with and without 2), same results,
> both succeed.
>
>> I hope it fails this way. If yes then maybe a way to construct a proper test
>> is to add a new vhost with very limited MaxRequestsPerChild (1 or 2)
>
> The key here is to make apache to fork a cgi process from the process (or its
> parent) that has called modperl_response_handler_cgi() before.
have you tried
$ t/TEST -one-process t/yourtest.t
?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Dmitry Karasik <dm...@karasik.eu.org>.
>
> 0) cd ModPerl-Registry/
> 1) start the testsuite with t/TEST -start-httpd
> 2) kill all apache children (workers). The supervisor apache should respawn
> new children.
> 3) Then run your test: t/TEST -run-tests -verbose t/stdin.t
No, it doesn't, it passes. I tried both with and without 2), same results,
both succeed.
> I hope it fails this way. If yes then maybe a way to construct a proper test
> is to add a new vhost with very limited MaxRequestsPerChild (1 or 2)
The key here is to make apache to fork a cgi process from the process (or its
parent) that has called modperl_response_handler_cgi() before.
--
Sincerely,
Dmitry Karasik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Torsten Foertsch <to...@gmx.net>.
On Tuesday 02 October 2007 08:54, Dmitry Karasik wrote:
> > Can you try the updated test patch that Torsten replied to the list with:
> >
> > http://marc.info/?l=apache-modperl&m=119074979901161&w=2
>
> The test succeeds in boths cases, on both patched and unpatched mod_perl.
> I don't know why is that, but I think that shouldn't be a reason to ignore
> the error that is reproduced using the test case I proposed (and
> of course because of the Pesticide Paradox :)
Try the following (assuming you are using prefork):
0) cd ModPerl-Registry/
1) start the testsuite with t/TEST -start-httpd
2) kill all apache children (workers). The supervisor apache should respawn
new children.
3) Then run your test: t/TEST -run-tests -verbose t/stdin.t
I hope it fails this way. If yes then maybe a way to construct a proper test
is to add a new vhost with very limited MaxRequestsPerChild (1 or 2)
Torsten
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Dmitry Karasik <dm...@karasik.eu.org>.
> Can you try the updated test patch that Torsten replied to the list with:
>
> http://marc.info/?l=apache-modperl&m=119074979901161&w=2
The test succeeds in boths cases, on both patched and unpatched mod_perl.
I don't know why is that, but I think that shouldn't be a reason to ignore
the error that is reproduced using the test case I proposed (and
of course because of the Pesticide Paradox :)
/dk
--
Sincerely,
Dmitry Karasik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] mod_perl closes apache's stdin and/or stdout
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
Dmitry Karasik wrote:
> Hello,
Hi Dmitry,
> As a follow-up to my previous bug report to users@,
> ( http://www.gossamer-threads.com/lists/modperl/modperl/94912 )
> I'd like to re-post the same issue to dev@, because I'm unsure
> what is the status of this bugreport, and basically if it
> was recognized as one.
Can you try the updated test patch that Torsten replied to the list with:
http://marc.info/?l=apache-modperl&m=119074979901161&w=2
you can run it via:
cd ModPerl-Registry
perl Makefile.PL && make && make test
once 'make test' has been run once, you can run that test individually with:
./t/TEST t/cgi-bin/stdin.t
It's really important to show a failing regression test here to prove
that it fails on your setup, but passes on other users' setups. I
looked through the thread and it looks like you are using a perlio
enabled perl, so that's probably not the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org