public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "vincent-srcware at vinc17 dot net" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/30157] parallel "make check" randomly skips tests
Date: Fri, 24 Feb 2023 09:02:28 +0000	[thread overview]
Message-ID: <bug-30157-131-RHH0djvmYl@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 #9 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(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.

> 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2023-02-24  9:02 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 [this message]
2023-02-24  9:22 ` vincent-srcware at vinc17 dot net
2023-02-25 19:04 ` carlos at redhat dot com
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-RHH0djvmYl@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).