On Fri, 3 Oct 2003, Stas Bekman wrote:
> 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?
I changed the message in mp2/src/modules/perl/modperl_io.c
(about line 139) to something unique, and the
Failed to dup DTDOUT: Permission denied
error is coming from there. And, like Steve mentioned, it
is coming from a select group of tests.
I've tried now a couple of things, but without success:
- redirecting STDOUT/STDERR to a temporary file within
the parent, and then calling run3 as
run3 $command, undef, undef, undef;
which is supposed to inherit the parent's STDs. This
worked fine on linux, but not on Win32.
- instead of using IPC::Run3, I wrote an equivalent thing
using Win32::Process, but ran into the same problem.
> 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?
It sounds like that might be happening, especially
since it's on a predictable subset of tests (eg,
apache/scanhdrs, but apache/constants is OK). I'll
try to put it through the debugger to see if that
sheds any light.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
