Hi, On Tue, Apr 16 2019, Jakub Jelinek wrote: > On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote: >> > I executed the dg-extract-results.sh manually in the gcc/testsuite >> > directory after a complete testsuite run which didn't give the correct >> > results. Rev. 240429 gives the expected results, where rev 268511 fails. >> > I'm on windows using msys2 with bash 4.4.23. >> > >> > I'm bootsrapping at the moment but that's really slow on windows. When >> > the testsuite run is finished I try to assemble a reproducer. This will >> > take a while. >> > >> >> OK, thanks! Do you mean the problem happens on Windows only? > > It is not on Windows only, I e.g. see the same problem on Linux too, > unfortunately only when doing package builds. > > E.g. > https://kojipkgs.fedoraproject.org//work/tasks/3883/34193883/build.log > In the ===TESTING=== section where it emits result of contrib/test_summary > the results look reasonable (though, the ordering looks random-ish even > when it is always LC_ALL=C, so if there are multiple FAILs, diffing them > from one build to another has -FAIL and +FAIL lines for the same tests), > but if you uudecode the file (with more recent uudecode one needs to extract > the begin ... end part manually, what a progress :( ) in the tarball any > *.log files changed with dg-extract-results.py contain just Running lines > and no further details. Others like libgomp.log are complete, but those are > not merged. I get those almost empty *.log files even after > rm -f contrib/dg-extract-results.py > (which should force the *.sh version). > > I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, > the *.log files are complete there. >
My experience might be completely unrelated, but I was getting empty *.sum files (the big merged ones) - and I believe also empty .log files but I am not longer sure - on a big Linux machine where a lot people build stuff and the reason was that I was hitting some maximum cgroup PID number limit that SUSE systemd invented for me/us in: /sys/fs/cgroup/pids/user.slice/user-$UID.slice/pids.max After setting that to "max" the problems never again materialized. In any event, it is worth checking whether some system limits do not prevent spawning new processes, I believe there were messages about it extractable from logs (or rather journalctl). Martin
