in reply to Bad file descriptor error in Win32 VC2015 compiled perl-5.20.3

Any Ideas?

I wonder if it's happening only under Test::Harness ?

You could check that by cd'ing to the Path-Tiny-0.084 build directory and running:
perl -Mblib t/00-report-prereqs.t
Does that still produce the same error ?

Afterthought: One thing that might serve as a perfectly acceptable workaround is, in Builder.pm's sub _open_testhandles(), to change the line:
return if $self->{Opened_Testhandles}; to return if 1;
Update: I've just noticed that the OP's aim is to reach an understanding of the problem - and that workaround won't help realise that understanding.

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: Bad file descriptor error in Win32 VC2015 compiled perl-5.20.3
by shadowsong (Pilgrim) on Mar 22, 2016 at 15:45 UTC

    Rob,

    Thanks for taking the time to chime in.

    It looks that way. Running perl -Mblib t\00-report-prereqs.t yields the following successful result:

    At the end of my response Re^2: Bad file descriptor error in Win32 VC2015 compiled perl-5.20.3 to BrowserUk, I outlined a bizarre observation wherein printing to STDOUT simply produced nothing

    Additionally

    From within the module directory - running perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t\00-report-prereqs.t yields the following unsuccessful result:

    >perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::H +arness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t\00-repo +rt-prereqs.t t\00-report-prereqs.t .. Can't dup STDOUT: Bad file descriptor at C:/ +perl-5.20.3/lib/Test/Builder.pm line 1952. Compilation failed in require at C:/perl-5.20.3/lib/Test/Builder/Modul +e.pm line 5. BEGIN failed--compilation aborted at C:/perl-5.20.3/lib/Test/Builder/M +odule.pm line 5. Compilation failed in require at C:/perl-5.20.3/lib/Test/More.pm line +23. BEGIN failed--compilation aborted at C:/perl-5.20.3/lib/Test/More.pm l +ine 23. Compilation failed in require at t\00-report-prereqs.t line 8. BEGIN failed--compilation aborted at t\00-report-prereqs.t line 8. t\00-report-prereqs.t .. Dubious, test returned 9 (wstat 2304, 0x900) No subtests run Test Summary Report ------------------- t\00-report-prereqs.t (Wstat: 2304 Tests: 0 Failed: 0) Non-zero exit status: 9 Parse errors: No plan found in TAP output Files=1, Tests=0, 0 wallclock secs ( 0.05 usr + 0.00 sys = 0.05 CPU +) Result: FAIL Failed 1/1 test programs. 0/0 subtests failed.

    Maybe the Test Harness is cocking up my STDOUT file descriptor?

    Cheers,
    Shadowsong

      Maybe the Test Harness is cocking up my STDOUT file descriptor?

      I've never managed to understand anything about problems that arise only when Test::Harness is invoked.
      (Best news would have been for you to report "Nope - makes no difference" ;-)

      perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t\00-report-prereqs.t


      A shot in the dark - does it make any difference if you remove undef *Test::Harness::Switches; from that command ?

      You mention another build of perl on another system where this problem does not arise.
      Do both systems run the same command when 'make test' is run ? (Obviously, they'll invoke different perls.)
      Do both systems run the same version of Test::Harness:
      perl -MTest::Harness -e "print $Test::Harness::VERSION"

      Cheers,
      Rob

        Rob - apologies for the late reply.

        A shot in the dark - does it make any difference if you remove undef *Test::Harness::Switches; from that command ?

        Removing undef *Test::Harness::Switches; from the command results in much the same - see error below:

        System 2 - where the problem isn't evident

        • Yes - both systems run the same command when make test is run
        • Yes - both systems run the same version of Test::Harness

        Test::Harness Version info on both systems

        It's quite bizarre and I'm out of ideas as to why my STDOUT file descriptor is evidently corrupt on the Win7 machine.