From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6D140385828D; Thu, 23 Feb 2023 13:35:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6D140385828D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677159335; bh=N0p3bTZtEEtdu5fM1r2RGdXK3vNRfLlTBL9BOsF0MiI=; h=From:To:Subject:Date:From; b=KEY1QGOGWFkGvZGfqcPvrYSfh/2V3Cfabe8Isly6VZkcCOXtNJXPI/gxQ1Gbv7Njj AZQS7tE23uki3Qovty1dJvqWpEfk1RPBwnICBS5LTjNNPVjZhNZ1sxsacu/FA+ZLsQ kIRawZsJWnQHz9731YyYlivTJconMVvhLpb342jU= From: "vincent-srcware at vinc17 dot net" To: glibc-bugs@sourceware.org Subject: [Bug build/30157] New: parallel "make check" randomly skips tests Date: Thu, 23 Feb 2023 13:35:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: build X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vincent-srcware at vinc17 dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30157 Bug ID: 30157 Summary: parallel "make check" randomly skips tests Product: glibc Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: build Assignee: unassigned at sourceware dot org Reporter: vincent-srcware at vinc17 dot net CC: carlos at redhat dot com Target Milestone: --- I did several "make check" yesterday (2023-02-22), and I did another one to= day (2023-02-23), and I can notice that some *.out files have not been rebuilt,= so if they were incorrect in the past, they are still incorrect, and at the en= d of the tests, "make check" considers the associated tests as failing: [...] -rw-r--r-- 1 50 2023-02-23 13:10:44 elf/tst-glibc-hwcaps.out -rw-r--r-- 1 43 2023-02-23 13:10:44 elf/tst-glibc-hwcaps-2.out -rw-r--r-- 1 68 2023-02-23 13:10:45 elf/tst-glibc-hwcaps-2-cache.out -rw-r--r-- 1 75 2023-02-23 13:10:45 elf/tst-glibc-hwcaps-cache.out -rw-r--r-- 1 0 2023-02-22 17:12:19 elf/tst-glibc-hwcaps-mask.out -rw-r--r-- 1 0 2023-02-22 17:12:19 elf/tst-glibc-hwcaps-prepend.out -rw-r--r-- 1 25 2023-02-23 13:10:45 elf/tst-glibc-hwcaps-prepend-cache.= out -rw-r--r-- 1 12 2023-02-23 13:10:44 elf/tst-global1.out -rw-r--r-- 1 16 2023-02-23 13:10:44 elf/tst-global2.out -rw-r--r-- 1 5 2023-02-23 13:10:44 elf/tst-gnu2-tls1.out -rw-r--r-- 1 583 2023-02-22 17:12:20 elf/tst-ifunc-fault-bindnow.out -rw-r--r-- 1 583 2023-02-22 17:12:20 elf/tst-ifunc-fault-lazy.out -rw-r--r-- 1 0 2023-02-23 13:10:44 elf/tst-ifunc-isa-1.out -rw-r--r-- 1 0 2023-02-23 13:10:43 elf/tst-ifunc-isa-1-static.out [...] Note: "make" is actually a shell wrapper that adds the appropriate -j option for parallelization (here -j12 as I have 12 cores) and colorizes the output. Yesterday, I initially did a "make check" where LD_PRELOAD was set to some library in the environment (as this is the case by default on my Debian account), and got 8 failures. Some of these failures were due to the LD_PRELOAD, so I tried again with LD_PRELOAD unset, but I got the same failures; however, I noticed that the corresponding *.out files had not been regenerated by the tests (their timestamp remained the same as before this = new test). Today I did a "make check" again with LD_PRELOAD unset, and this time I got only 5 failures. 3 of them are unrelated to LD_PRELOAD. But elf/tst-ifunc-fault-bindnow and elf/tst-ifunc-fault-lazy are due to LD_PREL= OAD, and the timestamp of their .out files corresponds to the time when I did the "make check" with LD_PRELOAD set. I suppose that 3 tests that now succeed h= ave been redone, so that their .out files have been rebuilt and are now correct. I suspect that the random behavior is due to the parallelized make. Possibly related to bug 22346 about another parallel "make check" issue. In= the summary of bug 29596 (for check-sim, now fixed): "unexpectedly passes witho= ut actually testing", which is more or less what happens here, except that thi= s is for me: unexpectedly fails without actually testing. --=20 You are receiving this mail because: You are on the CC list for the bug.=