perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <>
Subject Re: t/SMOKE on win32
Date Mon, 06 Oct 2003 07:04:01 GMT
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,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message