Closed shawnlaffan closed 8 months ago
Let's focus on t/85-myfile.t
. Please run
PAR_TMPDIR=some-existing-directory make test TEST_VERBOSE=1 TEST_FILES=t/85-myfile.t
so that executables built by pp don't get cleaned up end at the end of test, then examine the file named in the error message
# Failed test 'successfully ran "/var/folders/pt/h6h_6z6x5w75jzcd65r_s7zw0000gq/T/wnsA1xLMRn/pp000"'
# at ./t/utils.pl line 45.
# got: '9'
# expected: '0'
got
here is $? from running the executable.
Will do when I'm in front of that machine again, probably Friday AEDST.
t/85-myfile.t
passes when PAR_TMP_DIR
is set to a local dir.
Running the full set of tests with TMPDIR
set to the full path of a local dir results in only test pp_minus_lib_foo_minus_lib_bar_hello
from t/20-pp.t
failing.
Runningperl Makefile
and then make test
with both env vars set results in pp_test_small_minus_a
failing for one call but passing for another. Other tests fail on other runs.
So it would seem to be related to a system level constraint rather than PAR::Packer per se.
Pausing the backup system had no effect.
Inserting a sleep(1)
before https://github.com/rschupp/PAR-Packer/blob/d2305afb319783c0694b455abce77979319c196e/contrib/automated_pp_test/pipe_a_command.pm#L116 seems to make things pass.
Using unique names for the executable might be a solution but finding the best location at which do so is more challenging.
I can't see any "system level constraints" violated here, the code looks complicated (why read the command's output from a pipe, write it to a file, then read back that file?), but all filehandles are closed before proceeding....
Sprinkling sleep
s looks like voodo to me, it will also add 100 seconds to make test
.
automated_pp_test
is a mess. It was generated by some tool using some spec, both lost in the mist of time.
Its coding style is godawful, even in the non-generated parts. And it's only a unit test for pp
etc command line options. Maybe we should kill t/20-pp.t
?
My suspicion is that it's an antivirus scan that has not released the file by the time the next test tries to re-use that name. This machine is controlled by $work so I cannot disable such things.
The sleep was just a diagnostic step.
If t-20-pp.t
is not needed then it can go.
Another option is to increment the file names after each test. They are set in one location but there is a test counter that can be used after each test. It would be tedious but possible.
Another option is to increment the file names after each test. They are set in one location but there is a test counter that can be used after each test. It would be tedious but possible.
I'v done this now: all "toplevel" executables now have the test number in their name. However, several tests have subtests that reuse the per-test executable name. I've fixed the worst offenders by hand, but some duplicate names still remain.
Can you try the "ci" branch (passes on Linux and Windows)?
The tests still fails unfortunately, and inconsistently so. The example below is 18 (also failed 21), but the previous run failed for 19 and 23.
The is also using perl 5.36, so at least we can rule out 5.38.
Passing different executable name args seems to get the failing tests to pass (for a subset I checked) - usually this is the second test in the sub. The last test uses a different directory so is (should be) unaffected.
One does wonder what the benefit is to running the same test just with a different output dir, but I guess that's just one of the oddities of this test file.
not ok 18 - pp_minus_I_foo_minus_I_bar_hello
# [430]
# Test 18_1 The command string " ./a18.out " in directory /Users/shawn/git/PAR-Packer/contrib/automated_pp_test/pp_switch_tests/temp0,did not produce :: "hello" ::
# Instead, it produced ::
# The Line Below SHOULD BE "Can't locate ... along with a "BEGIN failed ... " line ::
# End of [430] results
#
# Did "/opt/homebrew/Cellar/perl/5.36.1/bin/perl" "/Users/shawn/git/PAR-Packer/blib/script/pp" -o "a18.out" -I "/Users/shawn/git/PAR-Packer/contrib/automated_pp_test/pp_switch_tests/temp0/subdir1" -I "/Users/shawn/git/PAR-Packer/contrib/automated_pp_test/pp_switch_tests/temp0/subdir2" "/Users/shawn/git/PAR-Packer/contrib/automated_pp_test/pp_switch_tests/temp0/foo.pl" produce a18.out?
#
# Failed test 'pp_minus_I_foo_minus_I_bar_hello
# [430]
# Test 18_1 The command string " ./a18.out " in directory /Users/shawn/git/PAR-Packer/contrib/automated_pp_test/pp_switch_tests/temp0,did not produce :: "hello" ::
# Instead, it produced ::
# The Line Below SHOULD BE "Can't locate ... along with a "BEGIN failed ... " line ::
# End of [430] results
#
# Did "/opt/homebrew/Cellar/perl/5.36.1/bin/perl" "/Users/shawn/git/PAR-Packer/blib/script/pp" -o "a18.out" -I "/Users/shawn/git/PAR-Packer/contrib/automated_pp_test/pp_switch_tests/temp0/subdir1" -I "/Users/shawn/git/PAR-Packer/contrib/automated_pp_test/pp_switch_tests/temp0/subdir2" "/Users/shawn/git/PAR-Packer/contrib/automated_pp_test/pp_switch_tests/temp0/foo.pl" produce a18.out?
# '
# at ./automated_pp_test.pl line 7660.
I fixed hopefully all subtests to use unique names for executables generated with $RUN_PP
, please try "ci" again.
Thanks. That seems to do the trick. All tests in t/20-pp.t
now pass.
Thanks for testing, released as 1.060
I just updated my local Mac to Sonoma (14.1.2).
After building perl 5.38.2 using perlbrew I see the failures below.
Running one of the generated files (
./contrib/automated_pp_test/pp_switch_tests/temp2/a.out
) produces this result:Please let me know what other debugging steps are needed.
====
Test results:
When using 5.38.0 only two tests fail (noting that this was built prior to the OS update):