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.

  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: link
Be 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).