Re: t/SMOKE on win32
On Thu, 2 Oct 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Fri, 3 Oct 2003, Randy Kobes wrote:
> >
> >>I've tried testing this, and haven't come across a problem
> >>yet, but this wasn't very extensive, as it's late ...
> >>(Stas, I've kept in the "print $log" statements just
> >>for debugging purposes).
> >
> >
> > I forgot - similar to an earlier fix for modperl_io.c,
> > I included the following:
> [...]
> > -status = Perl_do_open9(aTHX_ handle, "<:Apache", 8, FALSE, O_RDONLY,
> > +status = Perl_do_open9(aTHX_ handle, "<:Apache", 7, FALSE, O_RDONLY,
> > 0, Nullfp, sv, 1);
>
> why is that change? length("<:Apache") == 8, not 7...
I miscounted - sorry about that ...
--
best regards,
randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Randy Kobes wrote: Also, I just tried a long run (with the above change to modperl_io.c), and now I do get a (seemingly) random failure, but the error message is Failed to dup STDOUT: Permission denied and not STDIN. Not sure if this is progress ... I've rebuilt with Randy's revised IPC::Run3 patch for TestSmoke.pm (using undef instead of \undef), plus his patch to TestServer.pm, plus Stas' and my tweaks to modperl_io.c (changing ">&STDIN", 8 to "<&STDIN", 7). I think that's the current state of affairs. (And I didn't apply Randy's change to modperl_io.c that changed "<:Apache", 8 to "<:Apache", 7 ;-) It looks like the revision to the IPC::Run3 patch may have improved things slightly (?) because I now get the same error reported above by Randy every time: Failed to dup STDOUT: Permission denied. and no longer see any errors about STDIN. Again the error occurs on a random test and crashes the Apache server. Hunting around for possible causes I thought that these two lines in modperl_io.c's modperl_io_perlio_override_stdout(): status = Perl_do_open(aTHX_ handle_save, ">&STDOUT", 8, FALSE, O_RDONLY, status = Perl_do_open9(aTHX_ handle, ">:Apache", 8, FALSE, O_RDONLY, should perhaps be: status = Perl_do_open(aTHX_ handle_save, ">&STDOUT", 8, FALSE, O_WRONLY, status = Perl_do_open9(aTHX_ handle, ">:Apache", 8, FALSE, O_WRONLY, but sadly that didn't fix it either. I've turned on IPC::Run3 debug (I set it to 9, which I'm sure is overkill, to be sure) to see if that helps any. Here's the console output from the last-but-one test (which ran OK): = run3(): running 'C:\perl\bin\perl.exe C:/Temp/mod_perl-1.99_10/t/TEST -run modpe rl\current_callback.t' run3(): capturing child stdout run3(): $? is 0 run3(): reading child stdout to SCALAR run3(): read 127 bytes from child stdout: 'modperl\current_callbackok All tests successful. Files=1, Tests=1, 1 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) ' modperl\current_callbackok All tests successful. Files=1, Tests=1, 1 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) = and here's the output from the last test (which fell over): = run3(): running 'C:\perl\bin\perl.exe C:/Temp/mod_perl-1.99_10/t/TEST -run modul es\cgi.t' run3(): capturing child stdout run3(): $? is 256 run3(): reading child stdout to SCALAR run3(): read 529 bytes from child stdout: 'modules\cgi# Failed test 1 in mod ules\cgi.t at line 29 # Failed test 2 in modules\cgi.t at line 35 # Failed test 3 in modules\cgi.t at line 41 # Failed test 4 in modules\cgi.t at line 50 # Failed test 5 in modules\cgi.t at line 58 FAILED tests 1-5 Failed 5/5 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- modules\cgi.t55 100.00% 1-5 !!! error running tests (please examine t\logs\error_log) ' modules\cgi# Failed test 1 in modules\cgi.t at line 29 # Failed test 2 in modules\cgi.t at line 35 # Failed test 3 in modules\cgi.t at line 41 # Failed test 4 in modules\cgi.t at line 50 # Failed test 5 in modules\cgi.t at line 58 FAILED tests 1-5 Failed 5/5 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- modules\cgi.t55 100.00% 1-5 !!! error running tests (please examine t\logs\error_log) = I'll try to find something that reliably reproduces the problem, rather than scratching my head over these random failures... - Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Steve Hay wrote:
I'll try to find something that reliably reproduces the problem,
rather than scratching my head over these random failures...
Well, it seems that the problem with STDOUT is much more reproduceable
than the problem with STDIN was. I tried Smoking one of the tests that
a full Smoke run had fallen over on, and found that it falls over
straight away on its own. The same seems to be true of all the tests
that I've seen full Smoke runs die on. Thus, each of these commands
perl t/SMOKE modules\cgi
perl t/SMOKE modules\include
perl t/SMOKE apache\scanhdrs
perl t/SMOKE api\rflush
fall over ("Failed to dup STDOUT...") every time, while most other
tests, e.g.
perl t/SMOKE protocol\echo_filter
perl t/SMOKE hooks\stacked_handlers
perl t/SMOKE apache\post
perl t/SMOKE api\conn_rec
all run fine every time.
The above list of tests that fall over is almost certainly not complete
(discovering a complete list would be far too tedious), but hopefully
might help. The question is: What do the failing tests all do that the
working tests all don't do?
Damned if I can see the answer yet, though...
- Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] add PERL5LIB to @INC in the correct order
On Tue, 30 Sep 2003 11:49:57 -0700, Stas Bekman wrote
> Simon Flack wrote:
> > Problem:
> > at the beggining of each request PERL5LIB is prepended to @INC in
> > reverse order. E.g.:
> > SetEnv PERL5LIB "one:two:three:four"
> > results in this:
> > @INC = ('four', 'three', 'two', 'one', '/usr', '...');
> >
> > Environment:
> > Tested with perl 5.6.1, mod_perl 1.27 and 1.28
> >
> > A patch is attached to src/modules/perl/perl_util.c that adds the
PERL5LIB
> > variables in the correct order.
>
> Thank you Simon.
>
> It's a bug indeed. However I think we can't change this
> functionality in mp1 at this point, since it'll break other people's
> setups which rely on the current behavior. We probably should
> document this mis-feature.
Stas,
That's fine. Although the behaviour has changed as recently as v1.27 where
previously the contents of PERL5LIB were pushed onto @INC rather that
unshifted.
The problem with the current behaviour is that you need a special case when
running under mod_perl. In our set up, we test our scripts as CGIs and with
Apache::Registry and it's nice to be able to set PERL5LIB in one place rather
than two.
> Please use this as a workaround:
>
> my $PERL5LIB = "one:two:three:four";
> unshift @INC, $_ for reverse split /:/, $PERL5LIB;
We've done something like this, that works in mod_perl and non-mod_perl
environments:
SetEnv PERL5LIB one:two:three:four:three:two:one
Of course we have to explain that with a comment in case someone comes along
in a few months and thinks "I'll clean up that duplication"
We'll probably just apply the patch to our departmental servers and document
that in the build instructions.
Thanks
--simonflk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl 1.99_09 core dumps
Hi Stas For your information: I tried to compile mod_perl using the latest software versions: - perl-5.8.1 - httpd-2.0.47 - mod_perl-1.99_10 I still get the same error: ... /export/home/tperl/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean APXS= APACHE_PORT= APACHE_USER= APACHE_GROUP= APACHE= \ /export/home/tperl/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 /export/home/tperl/apache/bin/httpd -d /export/home/tperl/source/mod_perl-1.99_10/t -f /export/home/tperl/source/mod_perl-1.99_10/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.47 (prefork MPM) waiting for server to start: ...[Fri Oct 03 15:01:15 2003] [info] 23 Apache:: modules loaded [Fri Oct 03 15:01:15 2003] [info] 5 APR:: modules loaded [Fri Oct 03 15:01:15 2003] [info] base server + 10 vhosts ready to run tests ... waiting for server to start: giving up after 61 secs !!! server failed to start! (please examine t/logs/error_log) !!! oh crap, server dumped core !!! for stacktrace, run: gdb /export/home/tperl/apache/bin/httpd -core /export/home/tperl/source/mod_perl-1.99_10/t/core make: *** [run_tests] Error 1 [EMAIL PROTECTED] gdb /export/home/tperl/apache/bin/httpd -core /export/home/tperl/source/mod_perl-1.99_10/t/core GNU gdb 5.0 ... Loaded symbols for /export/home/tperl/source/mod_perl-1.99_10/blib/arch/auto/Apache/Module/Module.so #0 0xfdf4db58 in ap_pcw_walk_files_config (pconf=0x9ae58, s=0xb5010, dconf=0xb56d8, modp=0xfe05a384, dir_cb=0xfdf4d664 , data=0x0) at modperl_pcw.c:52 52 ap_conf_vector_t **dirs = (ap_conf_vector_t **)dconf->sec_file->elts; (gdb) bt #0 0xfdf4db58 in ap_pcw_walk_files_config (pconf=0x9ae58, s=0xb5010, dconf=0xb56d8, modp=0xfe05a384, dir_cb=0xfdf4d664 , data=0x0) at modperl_pcw.c:52 #1 0xfdf4de54 in ap_pcw_walk_config (pconf=0x9ae58, s=0xb5010, modp=0xfe05a384, data=0x0, dir_cb=0xfdf4d664 , srv_cb=0xfdf4d704 ) at modperl_pcw.c:106 #2 0xfdf4d8e4 in modperl_mgv_hash_handlers (p=0x9ae58, s=0xb5010) at modperl_mgv.c:473 #3 0xfdf3aec0 in modperl_hook_post_config (pconf=0x9ae58, plog=0xc4f00, ptemp=0xc6f08, s=0xb5010) at mod_perl.c:614 #4 0x37738 in ap_run_post_config (pconf=0x9ae58, plog=0xc4f00, ptemp=0xc6f08, s=0xb5010) at config.c:131 #5 0x4049c in main (argc=6, argv=0xffbefadc) at main.c:607 BR /Hans-Ruodi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
On Fri, 3 Oct 2003, Steve Hay wrote:
> Steve Hay wrote:
>
> > I'll try to find something that reliably reproduces the problem,
> > rather than scratching my head over these random failures...
>
> Well, it seems that the problem with STDOUT is much more reproduceable
> than the problem with STDIN was. I tried Smoking one of the tests that
> a full Smoke run had fallen over on, and found that it falls over
> straight away on its own. The same seems to be true of all the tests
> that I've seen full Smoke runs die on. Thus, each of these commands
>
> perl t/SMOKE modules\cgi
> perl t/SMOKE modules\include
> perl t/SMOKE apache\scanhdrs
> perl t/SMOKE api\rflush
>
> fall over ("Failed to dup STDOUT...") every time, while most other
> tests, e.g.
>
> perl t/SMOKE protocol\echo_filter
> perl t/SMOKE hooks\stacked_handlers
> perl t/SMOKE apache\post
> perl t/SMOKE api\conn_rec
>
> all run fine every time.
>
> The above list of tests that fall over is almost certainly not complete
> (discovering a complete list would be far too tedious), but hopefully
> might help. The question is: What do the failing tests all do that the
> working tests all don't do?
>
> Damned if I can see the answer yet, though...
I won't be able to try this until tomorrow, but a thought I
had was that, since passing in 'undef' for STDIN to run3 (so
that the child inherits the parent's STDIN) helps in
apparently getting rid of the errors for STDIN, it may be
worth trying that for STDERR and STDOUT as well. That is, do
the STDOUT and STDERR dups and redirections before calling
run3, at least for the tests. It's not pretty, but it may
help to nail down where the problem lies.
--
best regards,
randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Randy Kobes wrote:
On Fri, 3 Oct 2003, Steve Hay wrote:
Steve Hay wrote:
I'll try to find something that reliably reproduces the problem,
rather than scratching my head over these random failures...
Well, it seems that the problem with STDOUT is much more reproduceable
than the problem with STDIN was. I tried Smoking one of the tests that
a full Smoke run had fallen over on, and found that it falls over
straight away on its own. The same seems to be true of all the tests
that I've seen full Smoke runs die on. Thus, each of these commands
perl t/SMOKE modules\cgi
perl t/SMOKE modules\include
perl t/SMOKE apache\scanhdrs
perl t/SMOKE api\rflush
fall over ("Failed to dup STDOUT...") every time, while most other
tests, e.g.
perl t/SMOKE protocol\echo_filter
perl t/SMOKE hooks\stacked_handlers
perl t/SMOKE apache\post
perl t/SMOKE api\conn_rec
all run fine every time.
The above list of tests that fall over is almost certainly not complete
(discovering a complete list would be far too tedious), but hopefully
might help. The question is: What do the failing tests all do that the
working tests all don't do?
Damned if I can see the answer yet, though...
I won't be able to try this until tomorrow, but a thought I
had was that, since passing in 'undef' for STDIN to run3 (so
that the child inherits the parent's STDIN) helps in
apparently getting rid of the errors for STDIN, it may be
worth trying that for STDERR and STDOUT as well. That is, do
the STDOUT and STDERR dups and redirections before calling
run3, at least for the tests. It's not pretty, but it may
help to nail down where the problem lies.
I hope I've misinterpreted your instructions here, because what I've
just tried didn't work at all :-s
I applied the attached patch to the version of TestSmoke.pm that
included your most recent patch. This leaves the "undef" for STDIN, and
now changes STDOUT and STDERR to "undef" as well, having first
redirected them to the $log scalar. (I had to look up Perl's open()
manpage for that -- I didn't realise you could re-direct a filehandle to
a scalar! The manpage advises closing the affected filehandles before
attempting such re-direction, which is what I've done.)
I probably haven't done the right thing w.r.t. error handling -- I just
wanted to see if it worked.
It didn't.
Now when I run "perl t/SMOKE" I find that an Apache.exe is started, and
that's all! The SMOKE program exits and leaves Apache.exe running, but
didn't actually run any tests! There's nothing in the error_log (after
the server startup messages) either.
Hopefully I've just done it all wrong, and it'll work fine when you try
it!... :-)
- Steve
--- TestSmoke.pm.orig 2003-10-03 16:09:11.063158300 +0100
+++ TestSmoke.pm2003-10-03 16:09:52.656642100 +0100
@@ -506,7 +506,19 @@
my $test_command = "$command $test";
my $ok = 0;
my $log = '';
-run3 $test_command, undef, \$log, \$log;
+open my $savout, ">&STDOUT" or error "Can't dup STDOUT: $!\n";
+open my $saverr, ">&STDERR" or error "Can't dup STDERR: $!\n";
+close STDOUT;
+close STDERR;
+open STDOUT, \$log or error "Can't redirect STDOUT: $!\n";
+open STDERR, \$log or error "Can't redirect STDERR: $!\n";
+run3 $test_command, undef, undef, undef;
+close STDOUT;
+close STDERR;
+open STDOUT, '>&', $savout or error "Can't restore STDOUT: $!\n";
+open STDERR, '>&', $saverr or error "Can't restore STDERR: $!\n";
+close $savout;
+close $saverr;
print $log;
$ok = 1 if $log =~ /All tests successful/;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
On Fri, 3 Oct 2003, Steve Hay wrote: > Randy Kobes wrote: [ .. ] > >I won't be able to try this until tomorrow, but a thought I > >had was that, since passing in 'undef' for STDIN to run3 (so > >that the child inherits the parent's STDIN) helps in > >apparently getting rid of the errors for STDIN, it may be > >worth trying that for STDERR and STDOUT as well. That is, do > >the STDOUT and STDERR dups and redirections before calling > >run3, at least for the tests. It's not pretty, but it may > >help to nail down where the problem lies. > > > > > I hope I've misinterpreted your instructions here, because what I've > just tried didn't work at all :-s > > I applied the attached patch to the version of TestSmoke.pm that > included your most recent patch. This leaves the "undef" for STDIN, and > now changes STDOUT and STDERR to "undef" as well, having first > redirected them to the $log scalar. (I had to look up Perl's open() > manpage for that -- I didn't realise you could re-direct a filehandle to > a scalar! The manpage advises closing the affected filehandles before > attempting such re-direction, which is what I've done.) > > I probably haven't done the right thing w.r.t. error handling -- I just > wanted to see if it worked. > > It didn't. :( > > Now when I run "perl t/SMOKE" I find that an Apache.exe is started, and > that's all! The SMOKE program exits and leaves Apache.exe running, but > didn't actually run any tests! There's nothing in the error_log (after > the server startup messages) either. > > Hopefully I've just done it all wrong, and it'll work fine when you try > it!... :-) > > - Steve You tried essentially what I was thinking of ... The only thing I can think of changing at the moment is to use a different scalar ($log_stdout and $log_stderr) for capturing STDOUT and STDERR ... -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Steve Hay wrote: Randy Kobes wrote: Also, I just tried a long run (with the above change to modperl_io.c), and now I do get a (seemingly) random failure, but the error message is Failed to dup STDOUT: Permission denied and not STDIN. Not sure if this is progress ... I've rebuilt with Randy's revised IPC::Run3 patch for TestSmoke.pm (using undef instead of \undef), plus his patch to TestServer.pm, plus Stas' and my tweaks to modperl_io.c (changing ">&STDIN", 8 to "<&STDIN", 7). I think that's the current state of affairs. (And I didn't apply Randy's change to modperl_io.c that changed "<:Apache", 8 to "<:Apache", 7 ;-) It looks like the revision to the IPC::Run3 patch may have improved things slightly (?) because I now get the same error reported above by Randy every time: Failed to dup STDOUT: Permission denied. and no longer see any errors about STDIN. Again the error occurs on a random test and crashes the Apache server. Hunting around for possible causes I thought that these two lines in modperl_io.c's modperl_io_perlio_override_stdout(): status = Perl_do_open(aTHX_ handle_save, ">&STDOUT", 8, FALSE, O_RDONLY, status = Perl_do_open9(aTHX_ handle, ">:Apache", 8, FALSE, O_RDONLY, should perhaps be: status = Perl_do_open(aTHX_ handle_save, ">&STDOUT", 8, FALSE, O_WRONLY, status = Perl_do_open9(aTHX_ handle, ">:Apache", 8, FALSE, O_WRONLY, That sounds again as yet another copy-n-paste error. You are definitely correct. Though it seems that any of these problems totally unaffecting because we are in the dup mode. I'll commit your fix shortly. In any case, can we single out that IPC::Run3 causes this problem? Randy were you able to reproduce this problem with your original patch that uses Win32::Process. If that's the case with IPC::Run3, we should try again with standalone perl test script which dups STDOUT/STDIN and uses run3 to to spawn some external program that reads from STDIN and writes to STDOUT. If find such a test that reproduces the problem, besides having Barrie fixing it, he will have a good test to include in the IPC::Run3 tests suite ;) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Randy Kobes wrote: On Fri, 3 Oct 2003, Steve Hay wrote: Randy Kobes wrote: [ .. ] I won't be able to try this until tomorrow, but a thought I had was that, since passing in 'undef' for STDIN to run3 (so that the child inherits the parent's STDIN) helps in apparently getting rid of the errors for STDIN, it may be worth trying that for STDERR and STDOUT as well. That is, do the STDOUT and STDERR dups and redirections before calling run3, at least for the tests. It's not pretty, but it may help to nail down where the problem lies. I hope I've misinterpreted your instructions here, because what I've just tried didn't work at all :-s I applied the attached patch to the version of TestSmoke.pm that included your most recent patch. This leaves the "undef" for STDIN, and now changes STDOUT and STDERR to "undef" as well, having first redirected them to the $log scalar. (I had to look up Perl's open() manpage for that -- I didn't realise you could re-direct a filehandle to a scalar! The manpage advises closing the affected filehandles before attempting such re-direction, which is what I've done.) I probably haven't done the right thing w.r.t. error handling -- I just wanted to see if it worked. It didn't. :( Now when I run "perl t/SMOKE" I find that an Apache.exe is started, and that's all! The SMOKE program exits and leaves Apache.exe running, but didn't actually run any tests! There's nothing in the error_log (after the server startup messages) either. Hopefully I've just done it all wrong, and it'll work fine when you try it!... :-) - Steve You tried essentially what I was thinking of ... The only thing I can think of changing at the moment is to use a different scalar ($log_stdout and $log_stderr) for capturing STDOUT and STDERR ... That didn't make any difference :( I still worry that I've got something terribly wrong, though. Surely it should at least start running some tests? I was expecting it to either work, or else fail as before with the "Failed to dup STDOUT" error on certain (not-so-)random tests. Does my patch work on Linux? If not then I have got it all wrong, and we're not still staring at a Win32 problem. - Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl 1.99_09 core dumps
Hi Hans-Ruodi, For your information: I tried to compile mod_perl using the latest software versions: - perl-5.8.1 - httpd-2.0.47 - mod_perl-1.99_10 I still get the same error: That's for sure, since nothing has been done on this front. Philippe is now slowly coming back from the "oblivion", what do you expect from a guy who's just got married ;). Hopefully he will attend to this issue soonish. Thanks for being patient. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Steve Hay wrote: Does my patch work on Linux? If not then I have got it all wrong, and we're not still staring at a Win32 problem. Can you please post a patch against the current cvs, not against another patch? Thanks. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp1 patch] gv_fetchpv "Apache::write_client",
If this is a good idea, then shouldn't we also do it in the only other
place where we gv_fetchpv("",FALSE, ...) ?
Index: src/modules/perl/perlio.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perlio.c,v
retrieving revision 1.9
diff -u -I$Id: -r1.9 perlio.c
--- src/modules/perl/perlio.c 24 Mar 2002 02:17:10 - 1.9
+++ src/modules/perl/perlio.c 3 Oct 2003 18:10:07 -
@@ -108,7 +108,7 @@
Sfdisc_t* disc; /* discipline */
{
/* feed buffer to Apache->print */
-CV *cv = GvCV(gv_fetchpv("Apache::print", FALSE, SVt_PVCV));
+CV *cv = GvCV(gv_fetchpv("Apache::print", GV_ADDWARN, SVt_PVCV));
dSP;
ENTER;
SAVETMPS;
On Fri, 2003-08-29 at 20:08, Stas Bekman wrote:
> Some time ago, someone had a problem with a segfault when using Safe.pm, back
> then I wrote this patch. Perhaps it shouldn't go in as is, and we should just
> document that Safe.pm doesn't work with mod_perl, but this part is probably
> crucial:
>
> - CV *cv = GvCV(gv_fetchpv("Apache::write_client", FALSE, SVt_PVCV));
> +/* should exist already */
> +CV *cv = GvCV(gv_fetchpv("Apache::write_client", GV_ADDWARN, SVt_PVCV))
>
> I think it was Tim Bunce who suggested me to s/FALSE/GV_ADDWARN/. It doesn't
> add any overhead, but if gv_fetchpv fails and GV_ADDWARN is on, it'll log a
> warning, which a user can use to debug what the problem is.
>
> Index: src/modules/perl/Apache.xs
> ===
> RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
> retrieving revision 1.128
> diff -u -r1.128 Apache.xs
> --- src/modules/perl/Apache.xs 6 Jul 2003 04:51:20 - 1.128
> +++ src/modules/perl/Apache.xs 30 Aug 2003 02:26:31 -
> @@ -1134,7 +1134,9 @@
> sv_setiv(sendh, 0);
> }
> else {
> - CV *cv = GvCV(gv_fetchpv("Apache::write_client", FALSE, SVt_PVCV));
> +/* should exist already */
> +CV *cv = GvCV(gv_fetchpv("Apache::write_client", GV_ADDWARN, SVt_PVCV))
> ;
> +if(!cv) croak("can't find Apache::write_client, are you using Safe.pm?"
> );
> soft_timeout("mod_perl: Apache->print", r);
> PUSHMARK(mark);
> #ifdef PERL_OBJECT
>
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
signature.asc
Description: This is a digitally signed message part
Re: t/SMOKE on win32
Stas Bekman wrote: Steve Hay wrote: Does my patch work on Linux? If not then I have got it all wrong, and we're not still staring at a Win32 problem. Can you please post a patch against the current cvs, not against another patch? Thanks. It just hit me. Nothing that happens on the client side affects the server side's STD streams, since the two communicate over sockets. Are you sure that the "Failed to dup" error is coming from the server and not from the client? e.g change the server error message to something else just to make sure? If it is happening on the server side, may be it happens due to a previous request not restoring the overriden STD stream at the end of its run? We have the error checking, but it may fail nevertheless? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp1 patch] gv_fetchpv "Apache::write_client",
Philippe M. Chiasson wrote:
If this is a good idea, then shouldn't we also do it in the only other
place where we gv_fetchpv("",FALSE, ...) ?
+1
Index: src/modules/perl/perlio.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perlio.c,v
retrieving revision 1.9
diff -u -I$Id: -r1.9 perlio.c
--- src/modules/perl/perlio.c 24 Mar 2002 02:17:10 - 1.9
+++ src/modules/perl/perlio.c 3 Oct 2003 18:10:07 -
@@ -108,7 +108,7 @@
Sfdisc_t* disc; /* discipline */
{
/* feed buffer to Apache->print */
-CV *cv = GvCV(gv_fetchpv("Apache::print", FALSE, SVt_PVCV));
+CV *cv = GvCV(gv_fetchpv("Apache::print", GV_ADDWARN, SVt_PVCV));
dSP;
ENTER;
SAVETMPS;
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
On Fri, 3 Oct 2003, Steve Hay wrote:
> I still worry that I've got something terribly wrong,
> though. Surely it should at least start running some
> tests? I was expecting it to either work, or else fail as
> before with the "Failed to dup STDOUT" error on certain
> (not-so-)random tests.
>
> Does my patch work on Linux? If not then I have got it
> all wrong, and we're not still staring at a Win32 problem.
Actually, the patch did also make linux hang ... Here's
one which does work on linux - the intent here is to
dup/redirect STDOUT/STDERR before calling run3 $command,
so that run3 inherits the parent's STDOUT/STDERR/STDIN.
Index: Apache-Test/lib/Apache/TestSmoke.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestSmoke.pm,v
retrieving revision 1.23
diff -u -r1.23 TestSmoke.pm
--- Apache-Test/lib/Apache/TestSmoke.pm 12 Sep 2003 02:47:41 - 1.23
+++ Apache-Test/lib/Apache/TestSmoke.pm 3 Oct 2003 21:07:42 -
@@ -15,7 +15,8 @@
use FindBin;
use POSIX ();
use Symbol ();
-
+use IPC::Run3;
+use File::Temp qw(tempfile);
#use constant DEBUG => 1;
# how many times to run all tests at the first iteration
@@ -111,7 +112,7 @@
@{ $self->{tests} } = $self->get_tests($test_opts);
-$self->{base_command} = "./TEST";
+$self->{base_command} = "$^X $FindBin::Bin/TEST";
# options common to all
$self->{base_command} .= " -verbose" if $self->{verbose};
@@ -473,16 +474,13 @@
# start server
{
my $command = $self->{start_command};
-open my $pipe, "$command 2>&1|" or die "cannot fork: $!";
-my $oldfh = select $pipe; $| = 1; select $oldfh;
-# XXX: check startup success?
my $started_ok = 0;
my $log = '';
-while (my $t = <$pipe>) {
-$started_ok = 1 if $t =~ /started/;
-$log .= $t;
+unless ($log = run_command($command)) {
+error "Error running $command";
+exit 1;
}
-close $pipe;
+$started_ok = 1 if $log =~ /started/;
unless ($started_ok) {
error "failed to start server\n $log";
exit 1;
@@ -507,19 +505,14 @@
my $fill = "." x ($max_len - length $test_name);
$self->{total_tests_run}++;
-open my $pipe, "$command $test 2>&1|" or die "cannot fork: $!";
-my $oldfh = select $pipe; $| = 1; select $oldfh;
-
+my $test_command = "$command $test";
my $ok = 0;
my $log = '';
-while (<$pipe>) {
-$log .= $_;
-
-$ok = 1 if /All tests successful/;
+unless ($log = run_command($test_command)) {
+error "Error running $test_command";
+exit 1;
}
-# it's normal for $command to exit with a failure status if tests
-# fail, so we don't die/report it
-close $pipe;
+$ok = 1 if $log =~ /All tests successful/;
my @core_files_msg = $self->Apache::TestRun::scan_core_incremental;
@@ -594,16 +587,13 @@
# stop server
{
my $command = $self->{stop_command};
-open my $pipe, "$command 2>&1|" or die "cannot fork: $!";
-my $oldfh = select $pipe; $| = 1; select $oldfh;
-# XXX: check stopup success?
my $stopped_ok = 0;
my $log = '';
-while (my $t = <$pipe>) {
-$stopped_ok = 1 if $t =~ /shutdown/;
-$log .= $t;
+unless ($log = run_command($command)) {
+error "Error running $command";
+exit 1;
}
-close $pipe;
+$stopped_ok = 1 if $log =~ /shutdown/;
unless ($stopped_ok) {
error "failed to stop server\n $log";
exit 1;
@@ -628,6 +618,46 @@
}
+}
+
+sub run_command {
+my $command = shift;
+my ($fh, $file) = tempfile(UNLINK => 1);
+open my $savout, ">&STDOUT" or do {
+error "Can't dup STDOUT: $!";
+return;
+};
+open my $saverr, ">&STDERR" or do {
+error "Can't dup STDERR: $!";
+return;
+};
+close STDOUT; close STDERR;
+open STDOUT, '>', $file or do {
+error "Can't redirect STDOUT: $!";
+return;
+};
+open STDERR, '>&STDOUT' or do {
+error "Can't redirect STDERR: $!";
+return;
+};
+select STDERR; $| = 1;
+select STDOUT; $| = 1;
+run3 $command;
+close STDOUT; close STDERR;
+open STDOUT, '>&', $savout or do {
+error "Can't restore STDOUT: $!";
+return;
+};
+open STDERR, '>&', $saverr or do {
+error "Can't restore STDERR: $!";
+return;
+};
+close $savout; close $saverr;
+local $/;
+my $log = <$fh>;
+close $fh;
+print $log;
+return $log;
}
sub report_start {
==
Re: t/SMOKE on win32
On Oct 3 2003, Randy Kobes wrote: On Fri, 3 Oct 2003, Steve Hay wrote: > I still worry that I've got something terribly wrong, > though. Surely it should at least start running some > tests? I was expecting it to either work, or else fail as > before with the "Failed to dup STDOUT" error on certain > (not-so-)random tests. > > Does my patch work on Linux? If not then I have got it > all wrong, and we're not still staring at a Win32 problem. Actually, the patch did also make linux hang ... Here's one which does work on linux - the intent here is to dup/redirect STDOUT/STDERR before calling run3 $command, so that run3 inherits the parent's STDOUT/STDERR/STDIN. Unless I'm missing something, you should use system() then. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Barrie Slaymaker wrote: On Oct 3 2003, Randy Kobes wrote: On Fri, 3 Oct 2003, Steve Hay wrote: > I still worry that I've got something terribly wrong, > though. Surely it should at least start running some > tests? I was expecting it to either work, or else fail as > before with the "Failed to dup STDOUT" error on certain > (not-so-)random tests. > > Does my patch work on Linux? If not then I have got it > all wrong, and we're not still staring at a Win32 problem. Actually, the patch did also make linux hang ... Here's one which does work on linux - the intent here is to dup/redirect STDOUT/STDERR before calling run3 $command, so that run3 inherits the parent's STDOUT/STDERR/STDIN. Unless I'm missing something, you should use system() then. Then we can't read read its STDOUT/STDERR and if using backticks we can't control success/failure. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
On Fri, 3 Oct 2003, Barrie Slaymaker wrote: > On Oct 3 2003, Randy Kobes wrote: > > > On Fri, 3 Oct 2003, Steve Hay wrote: > > > > > I still worry that I've got something terribly wrong, > > > though. Surely it should at least start running some > > > tests? I was expecting it to either work, or else fail as > > > before with the "Failed to dup STDOUT" error on certain > > > (not-so-)random tests. > > > > > > Does my patch work on Linux? If not then I have got it > > > all wrong, and we're not still staring at a Win32 problem. > > > > Actually, the patch did also make linux hang ... Here's > > one which does work on linux - the intent here is to > > dup/redirect STDOUT/STDERR before calling run3 $command, > > so that run3 inherits the parent's STDOUT/STDERR/STDIN. > > Unless I'm missing something, you should use system() then. The above was just supposed to be a test, to see if it was from within IPC::Run3 that the problems about not being able to dup STDOUT arose. As Stas pointed out in another message, it's not clear if this is originating from the server or from the client side. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : [mp2] PERLIO_K_RAW in apr_perlio.c
On Wed, 1 Oct 2003, Stas Bekman wrote: > Randy Kobes wrote: > > On Thu, 2 Oct 2003, Randy Kobes wrote: > > > > > >>Here's a revised set of tests, using Geoff's implementation > >>of Apache::CRLF. This also addresses a couple of earlier > >>comments of Stas - the files used for comparison are now > >>assumed to be found as t/htdocs/perlio/http.pod and > >>t/htdocs/perlio/http_cycle.png. > > > > [ ... ] > > Sorry - I forgot - httpd.pod and http_cycle.png are in > > the mp2 cvs sources under docs/user/handlers/. If these > > files are OK to use, I'll add them to t/htdocs/perlio/ > > in cvs. This will mean adding perlio/ to cvs, if that's > > an issue? > > adding t/htdocs/perlio to cvs is fine. > > adding http.pod and http_cycle.png is not such a good > idea. The problem is that someone will try to read/use > them for other reasons and chances are that both will be > very out of date 6 months from now. Therefore if you can > use a file with your favorite poetry or prose for .pod > (call it .txt then) and small png of a flower that would > be much much better. Also it'd be nice to add not too big > files, as the source distribution is already quite big and > growing. Of course this is different if a big input is > needed for the test. You can use > http://www.google.ca/imghp to find images if you don't > have your own ;) Hi Stas, That's a good idea - thanks, I'll do that ... I don't think large files add anything to the tests, so I'll go with the small ones. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : [mp2] PERLIO_K_RAW in apr_perlio.c
On Wed, 1 Oct 2003, Stas Bekman wrote: > Randy Kobes wrote: > > On Wed, 1 Oct 2003, Geoffrey Young wrote: > > > >>or, I could just commit it now and Randy can decide which > >>route to go. I think I'll just do that... > > > > Here's a revised set of tests, using Geoff's implementation > > of Apache::CRLF. This also addresses a couple of earlier > > comments of Stas - the files used for comparison are now > > assumed to be found as t/htdocs/perlio/http.pod and > > t/htdocs/perlio/http_cycle.png, and also a constant > > data file name is used (and then cleaned up after the > > tests are done). > > tested OK on linux, +1 to commit with my other comments if > possible, or commit it as is and we will polish it later. Thanks very much Stas, and also for the earlier comments on where to declare things, etc. - much appreciated! I'll polish this up over the weekend and commit. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : [mp2] PERLIO_K_RAW in apr_perlio.c
On Wed, 1 Oct 2003, Stas Bekman wrote:
> Randy Kobes wrote:
[ .. ]
> Cool. The following are just style comments.
>
> > +# test reading and writing text and binary files
> > +{
> > +local $/;
>
> Randy, can you please put local $/; just before it's
> needed? Otherwise it's too far away from its usage and it
> may affect other things if the test is expanded in the
> future. The best practice IMHO is:
>
> {
>local $/;
>... <$fh>
> }
>
> in every place you need it. this makes the code easier to read.
Good idea - I'll do that ...
>
> > +my ($rfh, $wfh, $pfh);
>
> why these are defined outside and not where they are opened?
>
> open my $rfh, "<:APR", $in, $r->pool
>
> etc.
Done ...
>
> > +for my $file ('http.pod', 'http_cycle.png') {
> > +my $in = catfile $dir, $file;
> > +my $out = catfile $dir, "$file.out";
> > +open $rfh, "<:APR", $in, $r->pool
> > +or die "Cannot open $in for reading: $!";
> > +binmode($rfh); # not necessary
>
> if it's not necessary, why do we need it?
I'll drop the comment - it is too cryptic. But basically,
putting in a binmode($apr_fh) doesn't affect anything - you
can put it in, or leave it out, both for binary and text
files (even on Win32). Where having it in makes a difference
(but this doesn't matter to a user) is if PERLIO_K_RAW
was left out of apr_perlio.c. If it was, then all the
tests would pass without the binmode($apr_fh) calls, but
some will fail with a binmode($apr_fh).
[ .. ]
> I'd enclose the following code of its own block showing
> that it's an independent sub-test. you won't need to
> predeclare lexicals vars above. This practice makes easier
> to debug subtests where you can comment out blocks without
> affecting the rest of the test. see apr/pool.pm for such
> an example.
>
> > +my $scratch = catfile $dir, 'scratch.dat';
[ .. ]
I'll do that.
Thanks again, Stas.
--
best regards,
randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[mp1] 1.29 release candidate #1
The mod_perl 1.29 release candidate #1 has arrived. It can be
downloaded here:
http://www.apache.org/~gozer/mp1/mod_perl-1.28_01-dev-rc1.tar.gz
MD5 : 9f3e81dcdea7cdda3715631c25e446ef
SHA1: 1d14efb2ad89750dabcb3780b92992c1b8744551
The summary of what has changed since 1.28 are (from Changes):
Add a workaround for the 'rand' bug for perl 5.8.1 (compiled with
either -DUSE_HASH_SEED or -DUSE_HASH_SEED_EXPLICIT, which is the
default), causing all forked procs to produce the same rand
sequence. [Stas]
For Win32, add an INSTALL_LIB option to 'perl Makefile.PL' to
allow one to specify where to install mod_perl.lib. If not
given, this defaults to APACHE_SRC\libexec, if this exists.
Suggested by Steve Hay [randyk]
Fix t/net/perl/sym.pl (called by modules/symbol) not to affect other
tests (internal/http-get and internal/http-post, which were failing to
call exit) [Stas]
Fix Apache::ExtUtils to work with blead perl (it was breaking the
build) http://rt.perl.org/rt2/Ticket/Display.html?id=23803 [Stas]
On Win32 the uploaded file wasn't cleaned up (weither it's a bug in
CGI.pm or not), make sure we don't leave any dropped files around
[Steve Hay <[EMAIL PROTECTED]>]
For Win32, keep drive letters in mod_perl.dsp to fix bug, reported
by DH <[EMAIL PROTECTED]>, when compiling mod_perl in
cases where Apache and Perl are on different drives [Randy Kobes].
Add workaround to define statcache in Apache.xs so that
one can build on Win32 ActivePerl 8xx with LARGE_FILES
support [Randy Kobes]
--
A more detailled review of each patch included in this release candidate
can be found here:
http://www.apache.org/~gozer/mp1/1.28-dev/
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
