This appears to be a general clang 16 issue, not only to wsl2.

It is complaining about the use of uninit that is uninitialized here:

https://go.googlesource.com/go/+/78b42a5338aa1fa293acc5bbb7ef9122a7acc2ba/src/cmd/cgo/internal/testsanitizers/testdata/msan8.go#65

Shorter repro:

package main

/*
#include <stdint.h>

#include <sanitizer/msan_interface.h>

__attribute__((noinline))
void funinit(unsigned long a1) {}

static unsigned long uninit;

void f() {
	__msan_poison(&uninit, sizeof uninit);
	funinit(uninit);
}
*/
import "C"

func main() {
	C.f()
}

Strangely enough I can't seem to replicate it with a C version and clang-16.

Huh, something appear to have changed in clang-16 that makes it report memory as uninitialized in this case. From the test msan8 it reads:

// msanGoLoop loops calling msanGoWait, with the arguments passed
// such that msan thinks that they are undefined. msan permits
// undefined values to be used as long as they are not used to
// for conditionals or for memory access.

I tried clang 14, 15, 16, 17 and this only happens with clang >= 16. Looking at the release notes I can't spot anything that might've caused this change in msan behavior https://releases.llvm.org/16.0.0/docs/ReleaseNotes.html

I'm not sure if this comment above is actually a guarantee from the memory sanitizer, they might have changed it silently in clang-16 without mentioning it.

Here is a short C repro I put together that runs in clang 15 but not on clang 16:

// clang-16 -fsanitize=memory test.c && ./a.out
#include <stdint.h>
#include <sanitizer/msan_interface.h>

__attribute__((noinline))
void funinit(unsigned long a1) {}

static unsigned long uninit ;

void f() {
	__msan_poison(&uninit, sizeof uninit);
	funinit(uninit);
}

int main() {
    f();
    return 0;
}

Adjusting the labels as this appears to be a clang issue

cc @dvyukov

This looks like -fsanitize-address-param-retval (detects passing uninits as arguments), but it should be disabled by default. Maybe it was accidentally enabled in clang 16 and then disabled.
@kda @vitalybuka

It's enabled by default https://reviews.llvm.org/D134669

https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#sanitizers

Looks like that is the culprint, I was looking at the llvm release notes and not the tools, that is why I did not spot this change.

Thanks for the valuable insight @vitalybuka @dvyukov.

@bcmills Do you consider this as a breaking change? This new behavior seems to be beneficial for programs:

-fsanitize-memory-param-retval is turned on by default. With -fsanitize=memory, passing uninitialized variables to functions and returning uninitialized variables from functions is more aggressively reported. -fno-sanitize-memory-param-retval restores the previous behavior.

Should we retain the old behavior?

I think end users can control this using CGO_CFLAGS. So the breakage is not that bad.
And potentially we can go for the better/default behavior and gave users workaround via CGO_CFLAGS.

I think end users can control this using CGO_CFLAGS. So the breakage is not that bad. And potentially we can go for the better/default behavior and gave users workaround via CGO_CFLAGS.

The state of that flag for linked C/C++ code needs to be consistent with GO code. Mismatch either way will cause false positives.

Change https://go.dev/cl/549297 mentions this issue: cmd/cgo/internal/testsanitizers: fix msan test failing with clang >= 16

So it appears that we cannot use #if with #cgo, so the fix I submitted was reverted. I'm glad to hear suggestions on how to handle this.

@mauri870, perhaps the test driver itself could first try building with CGO_CFLAGS=-fno-sanitize-memory-param-retval, and try again without that flag if the build fails?