public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug build/30157] parallel "make check" randomly skips tests Date: Sat, 25 Feb 2023 19:04:47 +0000 [thread overview] Message-ID: <bug-30157-131-aCIYLNZR5I@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-30157-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=30157 --- Comment #11 from Carlos O'Donell <carlos at redhat dot com> --- (In reply to Vincent Lefèvre from comment #9) > (In reply to Carlos O'Donell from comment #8) > > I agree it doesn't answer your question, but it does set the expectation > > that anything you find that is not driven by dependencies is a mistake > > (barring some complexity around tests-container). > > Tests are there to find bugs, and bugs may depend on the run-time > environment in a broad sense (this may be environment variables, but also > the current time, the scheduling, in case of race conditions). So it does > not make much sense to say that if a test gave some result in some run, it > will always give the same result just because the source files have not > changed. Your are correct that the test results may vary depending on the system configuration, but what you're asking for is outside the current assumptions of the implementation. Describing the expectations highlights that the system is behaving *as expected*, but what you are asking for is an enhancement to the current build and test system. The build and test system *expects* a correctly configured developer system and optimizes for that to deduce developer iteration time to look at regression test results. If your system is incorrectly configured you may need to clean the whole build and start again or `find . -name *.out | xargs rm` or something similar. Could we do better? I expect we could. > > Have you seen tests that were incorrectly executed based on their > > dependencies? > > Yes, for instance, with 3 "make check" without a change of the source files > (thus needing a build of everything only after the first one[*]), but > LD_PRELOAD was unset after the first one, elf/tst-audit23 > * was executed after the first one (obviously) and failed due to the > LD_PRELOAD; > * was not executed after the second one; > * was executed after the third one (and no longer failed as LD_PRELOAD was > no longer set). > > [*] unless there is a bug in the dependencies for the build. (In reply to Vincent Lefèvre from comment #10) > I've done another "make check". So now there are tests whose last execution > is > * 2023-02-24 (today) > * 2023-02-23 > * 2023-02-22 around 17:43 > * 2023-02-22 around 17:12 (corresponding to the first "make check") > > (No source files have been changed after the initial checkout.) Just to be clear, while you say "No source files have been changed", what is actually important is *dependencies*. In the case of tst-audit23 we have the following: 2283 $(objpfx)tst-audit23.out: $(objpfx)tst-auditmod23.so \ 2284 $(objpfx)tst-audit23mod.so The tests need their output file (the *.out file) and this says that output needs the two audit modules compiled, so they get built before the test is built and run. I would be curious to know if the *.out file was changed, or the *.so files were changed, since they are are of the set of dependencies for the test. -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2023-02-25 19:04 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-23 13:35 [Bug build/30157] New: " vincent-srcware at vinc17 dot net 2023-02-23 13:39 ` [Bug build/30157] " vincent-srcware at vinc17 dot net 2023-02-23 13:43 ` vincent-srcware at vinc17 dot net 2023-02-23 14:03 ` sam at gentoo dot org 2023-02-23 14:10 ` schwab@linux-m68k.org 2023-02-23 14:15 ` vincent-srcware at vinc17 dot net 2023-02-23 14:54 ` vincent-srcware at vinc17 dot net 2023-02-23 16:18 ` schwab@linux-m68k.org 2023-02-23 17:38 ` vincent-srcware at vinc17 dot net 2023-02-23 19:05 ` carlos at redhat dot com 2023-02-24 9:02 ` vincent-srcware at vinc17 dot net 2023-02-24 9:22 ` vincent-srcware at vinc17 dot net 2023-02-25 19:04 ` carlos at redhat dot com [this message] 2023-02-25 20:47 ` vincent-srcware at vinc17 dot net
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30157-131-aCIYLNZR5I@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).