public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: elfutils-devel@sourceware.org
Subject: buildbot status
Date: Fri, 10 Sep 2021 15:14:32 +0200	[thread overview]
Message-ID: <a03a65f9de1fe76957792fc476ccbb02cf0cb65c.camel@klomp.org> (raw)

Hi,

Since the splitting of the mega debuginfod tests into separate
testcases we have seen some instability of the buildbot. I believe that
is mostly solved now.

I do sometimes see one of the run-debuginfod-federation-
{link,metric,sqlite}.sh tests fail when they are testing propagating of
a client request between servers when the request is for some symlinked
debuginfo. But when I showed that to Frank he immediately said that the
shell logic for that test was bogus, so I am hoping that when he cleans
that up that also gets rid of the false positives. At least we should
now get better error reports when something fails (previously a runtest
that failed, but not a normal shell command, would simply cleanup
instead of spitting out the metrics and server logs).

There also seems to be a spurious fail of the native core backtrace
test on centos-x86_64. I looked at it, but cannot really figure it out.
When it fails we believe to be in __clone inside libc.so.6 but at a pc
that doesn't have cfi, so we cannot unwind. Maybe this is simply a bug
in either the core file writing under centos7 or glibc really is
missing some cfi for clone. But that doesn't explain why it is non-
deterministic.

Finally things took a really long time because most buildbot workers
were doing a full distcheck, which involves a normal build, a normal
make check, generating a dist tar ball, unpacking it again, valgrind,
the gcc undefined   sanitizer, a srcdir == builddir, a srcdir !=
builddir, an install check and another build check. On some builders
this took more than an hour. And for some reason the s390x builder was
so slow that it took 6 hours (!) for each commit.

So I have reconfigured the builders a bit:

- Only elfutils-fedora-x86_64 does a full distcheck
- elfutils-centos-x86_64, elfutils-debian-amd64, elfutils-debian-i386,
  elfutils-fedora-ppc64le and elfutils-fedora-s390x
  configure --enable-valgrind --enable-sanitize-undefined and do a
  make && make check
- elfutils-debian-arm64
  configure --enable-valgrind && make && make check
- elfutils-fedora-ppc64 and elfutils-debian-armhf
  configure without valgrind and sanitizer and simply
  make && make check

Hopefully that gives us buildbot results a bit quicker.

Cheers,

Mark

                 reply	other threads:[~2021-09-10 13:14 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=a03a65f9de1fe76957792fc476ccbb02cf0cb65c.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@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).