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]

Reply via email to