From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106801 invoked by alias); 16 Apr 2019 15:48:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 106784 invoked by uid 89); 16 Apr 2019 15:48:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_50,KAM_NUMSUBJECT,SPF_PASS autolearn=no version=3.3.1 spammy=H*f:sk:d9a1dd7, 4423, bootsrapping, msys2 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Apr 2019 15:48:50 +0000 X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 72979AEEE; Tue, 16 Apr 2019 15:48:48 +0000 (UTC) From: Martin Jambor To: Jakub Jelinek , Christophe Lyon Cc: Rainer Emrich , gcc Mailing List Cc: Subject: Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32 In-Reply-To: <20190416134444.GH21066@tucnak> References: <20190415153842.GU21066@tucnak> <34226dcf-24e4-370f-0f88-a69d979aef2e@emrich-ebersheim.de> <97c67265-af2a-b3f2-eecc-168abf4b5a6c@emrich-ebersheim.de> <8baf303a-9f01-15ec-7bbc-7b3419a96f00@emrich-ebersheim.de> <782fe033-0797-5574-0d62-af3ab4bf881e@emrich-ebersheim.de> <504c2014-9764-c638-bf3a-0802132eb475@emrich-ebersheim.de> <20190416134444.GH21066@tucnak> User-Agent: Notmuch/0.28.3 (https://notmuchmail.org) Emacs/26.1 (x86_64-suse-linux-gnu) Date: Tue, 16 Apr 2019 15:48:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00175.txt.bz2 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