On Fri, 3 Oct 2003, Steve Hay wrote:I hope I've misinterpreted your instructions here, because what I've just tried didn't work at all :-s
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 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.pm 2003-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]
