From: Jeff King <peff@peff.net>
To: Philippe Blain <levraiphilippeblain@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>
Subject: Re: Failures in GitHub Actions linux-leaks and linux-asan-ubsan
Date: Mon, 18 Mar 2024 05:08:48 -0400 [thread overview]
Message-ID: <20240318090848.GC602575@coredump.intra.peff.net> (raw)
In-Reply-To: <3e217121-f49b-33bd-b76f-df24efca6d14@gmail.com>
On Sat, Mar 16, 2024 at 03:20:44PM -0400, Philippe Blain wrote:
> The failures are due to the new ubuntu-22.04 GitHub Actions image
> (release 20240310.1.0, [1]) which uses a kernel where ASLR is configured
> in a way that is incompatible with ASan and LSan as used in
> the GCC and Clang versions in that image. More info can be found
> in [2] and [3] and pages linked there.
>
> A workaround was already implemented in the image generation process
> [4], so the next version of the image should work. I think the images
> are released weekly. We could maybe add the same sysctl command to reduce
> the entropy to our YAML file, or we could live with it for the next week
> or so while waiting for the next image to roll out.
Thanks for digging into this! I had done a little but didn't get nearly
as far. I am happy I can just ignore it and the problem will resolve
itself. ;)
While I have the attention of folks who might be interested in CI
failures, let me hijack the thread for a moment: has anybody figured out
why macOS jobs sometimes time out after 6 hours? I assume that is an
Actions limit, and something is just hanging. It sometimes hits
osx-reftable[0], but sometimes osx-clang[1] and osx-gcc[2]. I've seen it
on my builds and some on git/git (the last one is from git/git).
It's hard to tell which test is hanging, because the output only shows
the finished tests. I tried running them without "prove" and doing it
one-by-one, but then the hang doesn't seem to occur (so presumably it's
a race under load). I tried comparing the list of tests reported as
finishing versus the total list, but there was nothing enlightening.
It's all stuff in t9xxx, which you'd expect to be running near the end
anyway (and it feels like if there was _one_ test hanging, we should
finish everything else, since we run with some parallelism). So it's
almost like a bug in "prove" or something. But AFAIK it just started
happening in the past month or two.
-Peff
[0]: example run: https://github.com/peff/git/actions/runs/8107092556/job/22158038562
[1]: example run: https://github.com/peff/git/actions/runs/8091601551/job/22110929146
[2]: example run: https://github.com/git/git/actions/runs/8273234891/job/22636626511
prev parent reply other threads:[~2024-03-18 9:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-16 19:20 Failures in GitHub Actions linux-leaks and linux-asan-ubsan Philippe Blain
2024-03-16 23:31 ` Junio C Hamano
2024-03-18 6:52 ` Linus Arver
2024-03-18 9:08 ` Jeff King [this message]
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=20240318090848.GC602575@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=levraiphilippeblain@gmail.com \
/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