Description
Every once in a while, a win test
or win+VS test
job in our CI runs fails with a very obscure "Parse errors: No plan found in TAP output" bread-crumb left behind in the prove
output. Example:
[23:56:45] unit-tests/bin/t-strbuf.exe ..................... ok 1 s ( 0.00 usr 0.02 sys + 0.03 cusr 0.17 csys = 0.21 CPU)
[23:56:45] t9135-git-svn-moved-branch-empty-file.sh ........ skipped: skipping git svn tests, NO_SVN_TESTS defined
[23:56:45] unit-tests/bin/t-strcmp-offset.exe .............. ok 1 s ( 0.00 usr 0.02 sys + 0.54 cusr 1.31 csys = 1.87 CPU)
[23:56:45] unit-tests/bin/t-trailer.exe .................... ok 1 s ( 0.00 usr 0.00 sys + 0.51 cusr 1.29 csys = 1.80 CPU)
[23:56:45] unit-tests/bin/t-urlmatch-normalization.exe ..... ok 1 s ( 0.00 usr 0.00 sys + 0.53 cusr 1.27 csys = 1.80 CPU)
[23:56:45] unit-tests/bin/unit-tests.exe ................... ok <1 s ( 0.00 usr 0.00 sys + 0.54 cusr 1.24 csys = 1.79 CPU)
[23:56:45] t0071-sort.sh ................................... ok 4 s ( 0.00 usr 0.08 sys + 3.74 cusr 9.97 csys = 13.79 CPU)
[23:56:48] unit-tests/bin/t-reftable-stack.exe ............. ok 4 s ( 0.00 usr 0.05 sys + 1.00 cusr 2.67 csys = 3.72 CPU)
[23:56:52] t0302-credential-store.sh ....................... ok 108 s ( 0.09 usr 0.30 sys + 72.16 cusr 177.20 csys = 249.76 CPU)
[23:56:55] t3906-stash-submodule.sh ........................ ok 37 s ( 0.02 usr 0.16 sys + 28.74 cusr 72.28 csys = 101.20 CPU)
[23:56:58] t1300-config.sh ................................. ok 302 s ( 0.24 usr 0.58 sys + 146.59 cusr 356.84 csys = 504.24 CPU)
[23:56:58]
Test Summary Report
-------------------
t7513-interpret-trailers.sh (Wstat: 256 (exited 1) Tests: 24 Failed: 0)
Non-zero exit status: 1
Parse errors: No plan found in TAP output
Files=124, Tests=2693, 302 wallclock secs ( 0.25 usr 0.61 sys + 146.59 cusr 356.84 csys = 504.29 CPU)
Result: FAIL
make: *** [Makefile:73: prove] Error 1
++ cat exit.status
+ res=2
+ rm exit.status
+ end_group 'Run tests'
+ test -n t
+ set +x
=== Failed test: t7513-interpret-trailers ===
The full logs are in the 'print test failures' step below.
See also the 'failed-tests-*' artifacts attached to this run.
Error: Process completed with exit code 1.
Looking at those test failures shows some two dozen lines with the error mentioned in this ticket's title. Example:
0 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
962 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
./test-lib.sh: fork: retry: Resource temporarily unavailable
1554205 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
2566469 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
3112806 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
4122000 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
./test-lib.sh: fork: retry: Resource temporarily unavailable
4666365 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
6228598 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
7694614 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
7786764 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
9253621 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
./test-lib.sh: fork: retry: Resource temporarily unavailable
9346422 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
10904208 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
12460296 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
14020585 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
14818246 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
15582141 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
16373295 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
./test-lib.sh: fork: retry: Resource temporarily unavailable
17136204 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
18694786 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
20236375 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
21798608 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
23354580 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
24908795 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
25936958 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
26465152 [sig] sh 529 sig_send: error sending signal 11, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
27493410 [main] sh 529 sig_send: error sending signal -72, pid 529, pipe handle 0x14C, nb 0, packsize 176, Win32 error 0
./test-lib.sh: fork: Resource temporarily unavailable
FATAL: Unexpected exit with code 254
This error message has been mentioned on the Cygwin mailing list in 2022, seemingly without any traction seeing as the proposed patch never made it into Cygwin, at least I cannot find it, even on their master
branch.
The same error message was mentioned again in July '24, this time on the cygwin-developers
mailing list, again without any traction.
Maybe we should integrate the proposed work-around into the MSYS2 runtime and see whether it improves things?