ffi_2/function_callbacks_test crashing on dartk-msan-linux-release-x64

[crelier]

MemorySanitizer thinks that std::cout is not initialized in the tests ffi_2/function_callbacks_test/0 .. ffi_2/function_callbacks_test/8

The crashes disappear if the line printing to std::cout is commented out:
https://github.com/dart-lang/sdk/blob/master/runtime/bin/ffi_test/ffi_test_functions.cc#L1009

The crashes also disappear if this flag is removed when building the test:
--exclude-libs=libc++.a

Note that this flag was added here: https://dart-review.googlesource.com/c/sdk/+/115403

Repro steps:

./tools/build.py -v --mode=release --sanitizer=msan -ax64 runtime
python tools/test.py -n dartk-msan-linux-release-x64 ffi_2/function_callbacks_test

Here is an output example:

DART_CONFIGURATION=ReleaseMSANX64 out/ReleaseMSANX64/dart --use-bare-instructions=false --ignore-unrecognized-flags --packages=/usr/local/google/home/regis/dart2/sdk/.packages /usr/local/google/home/regis/dart2/sdk/tests/ffi_2/function_callbacks_test.dart

exit code:
-6

stdout:
simpleAddition(10, 20)
intComputation(125, 250, 500, 1000)
intComputation(0, 0, 0, 9223372036854775807)
intComputation(0, 0, 0, -9223372036854775808)
uintComputation(0, 0, 0, 9223372036854775807)
uintComputation(0, 0, 0, -9223372036854775808)
uintComputation(0, 0, 0, -1)
simpleMultiply(2.0)
simpleMultiplyFloat(2.0)
manyInts(1, 2, 3, 4, 5, 6, 7, 8, 9, 10
manyDoubles(1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0
manyArgs( 1, 2.0, 3, 4.0, 5, 6.0, 7, 8.0, 9, 10.0,11, 12.0, 13, 14.0, 15, 16.0, 17, 18.0, 19, 20.0)
takeMaxUint8x10(255, 255, 255, 255, 255, 255, 255, 255, 255, 255)
takeMaxUint8x10(255, 255, 255, 255, 255, 255, 255, 255, 255, 255)

stderr:
==96121==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f5c41ead9bc in std::__2::basic_ostream<char, std::__2::char_traits<char> >& std::__2::__put_character_sequence<char, std::__2::char_traits<char> >(std::__2::basic_ostream<char, std::__2::char_traits<char> >&, char const*, unsigned long) ../../out/ReleaseMSANX64/../../buildtools/linux-x64/clang/bin/../include/c++/v1/ostream:727:13
    #1 0x7f5c41ead371 in std::__2::basic_ostream<char, std::__2::char_traits<char> >& std::__2::operator<<<std::__2::char_traits<char> >(std::__2::basic_ostream<char, std::__2::char_traits<char> >&, char const*) ../../out/ReleaseMSANX64/../../buildtools/linux-x64/clang/bin/../include/c++/v1/ostream:869:12
    #2 0x7f5c41ead371 in TestReturnMaxUint8 ../../out/ReleaseMSANX64/../../runtime/bin/ffi_test/ffi_test_functions.cc:1009:13

SUMMARY: MemorySanitizer: use-of-uninitialized-value ../../out/ReleaseMSANX64/../../buildtools/linux-x64/clang/bin/../include/c++/v1/ostream:727:13 in std::__2::basic_ostream<char, std::__2::char_traits<char> >& std::__2::__put_character_sequence<char, std::__2::char_traits<char> >(std::__2::basic_ostream<char, std::__2::char_traits<char> >&, char const*, unsigned long)
Exiting

--- Re-run this test:
python tools/test.py -n dartk-msan-linux-release-x64 ffi_2/function_callbacks_test/8
[00:02 | 100% | +   10 | -    9]

[dcharkes]

The crashes also disappear if this flag is removed when building the test:
--exclude-libs=libc++.a

I cannot reproduce this locally @crelier. Commenting out the following lines does not make the false positives disappear.

sdk/build/config/linux/BUILD.gn

Lines 11 to 14 in 73f6d15

	if (is_clang) {
	# Don't allow visible symbols from libc++ to be re-exported.
	ldflags += [ "-Wl,--exclude-libs=libc++.a" ]
	}

Is there something I'm missing @crelier?

According to the documentation we need to actually make sure we use a msan instrumented version of libc++.

If you want MemorySanitizer to work properly and not produce any false positives, you must ensure that all the code in your program and in libraries it uses is instrumented (i.e. built with -fsanitize=memory). In particular, you would need to link against MSan-instrumented C++ standard library.

https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo

[crelier]

@dcharkes you are right. Removing the flag --exclude-libs=libc++.a does not help anymore. Something must have changed since this issue was filed.

[dcharkes]

This is caused by the clang toolchain that we pull in through DEPS, it doesn't provide an MSAN instrumented libc++.

We don't currently ship MSan instrumented libc++ in our toolchain (not even for the host) so this is working as expected. We could but it's not entirely trivial because we would have to figure out the sanitizer multilib support for platforms other than Fuchsia.

[mkustermann]

Closing in favor of #44377