This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
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