Sanitizer enablement tracking issue

[Keno]

This is an issue for everything that needs to happen, so we can start regularly using the sanitizers, both on CI and elsewhere. It's quite a bit, requires some coordination and I don't want to forget everything, so a long checklist it is.

• Merge Make jl_datatype_size reflect non-padded field size #46322 or Fix stack-buffer-overflow in generated code #46260 or Properly declare alloca alignment #46368 to fix asan complaint in generated code
• Merge Make ASAN actually do something and fix all the things #46336
• Merge [ASAN] Turn off asan instrumentation in segv handler #46377
• [Optional, but good to have] Do something about asan fake stack can free live stack frames after longjmp/signal google/sanitizers#1561
• Enable asan on CI
  • One CI job every commit running read/channels/spawn
  • One nightly job running full bootstrap + testsuite
• Add msan llvm patches to julia build
  • Backport llvm/llvm-project@15972e3
  • https://reviews.llvm.org/D131845
    • And merge it upstream
  • https://reviews.llvm.org/D131846
    • And merge it upstream
  • The patch from Detect dynamic TLS allocations for glibc>=2.19 google/sanitizers#1409 (comment) (or something better)
• Finish and merge Enable MSAN support again #46348
• Merge Add support for building sanitizer-enabled jlls JuliaPackaging/BinaryBuilderBase.jl#255
  • ... and deploy on Yggdrasil (Bump BBB and test dSFMT sanitizer build  JuliaPackaging/Yggdrasil#5315)
• Have julia detect its sanitizer status and add platform tags
  • In the build system (Teach bb-install.mk to pick up special jlls for msan #46418)
  • In Pkg
• Fix test failures under msan
  • compiler/codegen
  • compiler/contextual
  • atomics
  • strings/search
  • spawn
  • compiler/inference
  • regex
  • namedtuple
  • llvmcall
  • float16
  • operators
  • ryu
  • loading
  • meta
  • stacktraces
  • error
  • misc
  • download
  • asyncmap
  • LibGit2
  • core
  • LinearAlgebra/qr (LinearAlgebra/qr: Stop trying to factorize uninitialized memory #46386)
• Patch our dependencies to add __msan_unpoison around asm code
• Merge [WIP] Recipe to build libstdcxx with msan JuliaPackaging/Yggdrasil#5308 to get msan-enabled libstdcxx Merge Add a standalone LibStdCxx jll JuliaPackaging/Yggdrasil#5331
  • Merge Bump LibStdCxx to gcc 12 JuliaPackaging/Yggdrasil#5335
  • Merge Add "libabi_agnostic" JuliaPackaging/BinaryBuilderBase.jl#257
  • Merge [CSL] Use libstdcxx from jll JuliaPackaging/Yggdrasil#5336
• Merge New Recipe: FlangClassic JuliaPackaging/Yggdrasil#5311 to get an msan-capable fortran compiler
• Build -sanitizer versions of all our dependencies
  • dSFMT Bump BBB and test dSFMT sanitizer build  JuliaPackaging/Yggdrasil#5315
  • OpenBLAS OpenBLAS: Build for msan JuliaPackaging/Yggdrasil#5322
• Set up msan CI
• [Optional] Add a BinaryBuilder audit pass to make sure that the sanitizing actually happened
• [Optional] Make sanitizers more precise around our GC allocations.
  • Add ASAN guards to our GC objects.
• [Optional] Add a way to build sanitizer-enabled sysimages from non-sanitizer builds
• [Optional] msan test suite
  • Add an LLVM attribute to set the msan "recover" option on a per-function basis.
• [Optional] Sanitizer symbolization of jit frames

[gbaraldi]

What about TSAN, not sure if it's going to help anywhere, but it looks like we currently just build the julia runtime with it, nothing more.

[Keno]

What about TSAN, not sure if it's going to help anywhere, but it looks like we currently just build the julia runtime with it, nothing more.

I think tsan is mostly working, but I haven't played with it extensively yet. For now, the target here it get asan/msan working well to hopefully stop memory issues in external libraries from breaking CI as frequently as they have been.

[gbaraldi]

What I meant is that we should do something with it. I believe we just build the runtime for now and maybe we should run at least the Threads testset with it on.

[gbaraldi]

Deps to build:

• GMP
• LibCurl
• LibGit2
• LibSSH2
• LibUV
• LibUnwind
• MbedTLS
• PCRE2
• OpenLibm
• SuiteSparse
• libblastrampoline
• nghttp2
• p7zip

[gbaraldi]

Using the PR, which kind of works I've been compiling a couple of failures. The atomic failure seems to be related to padding, and a MWE is

mutable struct ARefxy{T}
    @atomic x::T
    y::T
end

struct PadIntA <: Number # internal padding
    a::Int8
    b::Int16
end

r = ARefxy{PadIntA}(PadIntA(15,12), PadIntA(15,12))
replacefield!(r, :x, PadIntA(15,11), PadIntA(15,12), :sequentially_consistent, :sequentially_consistent)

I'm not sure what the correct thing here is, maybe we should just unpoison it since we know we are moving padding around.