This could be a variant of fuzz_driver built with -fsanitize=memory if supported. We'll probably need to modify the ci script to get a working memory sanitizer environment going though
This could be a variant of fuzz_driver built with -fsanitize=memory if supported. We'll probably need to modify the ci script to get a working memory sanitizer environment going though
weaselbot
was assigned by andrew2026-07-22 20:20:50 +00:00
I looked into this and hit a real blocker around the sanitizer environment, so I'm pausing before opening a PR.
What I found
A msan_driver variant of fuzz_driver (built from ConflictSet.cpp + FuzzTestDriver.cpp with -fsanitize=memory) compiles and links fine, and -fsanitize=memory is supported by the clang we use in CI. The masked-but-unused reads that the code already annotates for valgrind (VALGRIND_MAKE_MEM_DEFINED in checkMaxBetweenExclusiveImpl) are not an msan problem — msan's bitwise shadow propagation correctly clears the masked-out bits, so those loops stay clean.
The actual blocker is the well-known msan requirement that the whole program, including the C++ standard library, be instrumented. With an uninstrumented libstdc++/libc++:
The harness itself (std::ifstream/std::stringstream in FuzzTestDriver.cpp) immediately reports a false-positive use-of-uninitialized-value from str.data(), because the file read happens in uninstrumented library code. I confirmed this locally.
Switching the harness to C I/O (fread, which msan intercepts) moves the report into the test driver's std::set<std::string_view, ..., ArenaAlloc<...>> usage in TestDriver::next() (Internal.h:~658) — _Rb_tree::_M_get_insert_unique_pos reading a node's _M_left. I couldn't determine whether that's a genuine uninitialized read or an msan/stdlib imprecision without an instrumented stdlib to compare against.
What a working environment needs
The standard, documented way to run msan on C++ is to build an msan-instrumented libc++/libc++abi/libunwind from the LLVM source (e.g. via runtimes with -DLLVM_USE_SANITIZER=Memory) and build msan_driver against it (-stdlib=libc++ + a sysroot/-B pointing at the instrumented libs). That's a non-trivial addition to the CI job — it needs the LLVM runtimes source and an extra build step — and I can't build/validate that instrumented-stdlib pipeline from this sandbox (no apt, can't clone llvm-project), so I don't want to ship an untested heavy CI job that would just go red.
What I'd like to confirm
Is building an msan-instrumented libc++ from LLVM source in CI (with the extra runtime cost) the approach you want, or do you have a preferred prebuilt msan sysroot / environment in mind?
Once that environment is in place, msan does surface a report in the test driver's std::set (Internal.h ~658). Are you expecting that to be a real bug to fix, or should I treat test-driver-only findings as out of scope and annotate/suppress them?
Once you point me at the preferred environment, I'll add the USE_MSAN CMake target + the CI job and follow up with a PR.
I looked into this and hit a real blocker around the sanitizer environment, so I'm pausing before opening a PR.
## What I found
A `msan_driver` variant of `fuzz_driver` (built from `ConflictSet.cpp` + `FuzzTestDriver.cpp` with `-fsanitize=memory`) compiles and links fine, and `-fsanitize=memory` is supported by the clang we use in CI. The masked-but-unused reads that the code already annotates for valgrind (`VALGRIND_MAKE_MEM_DEFINED` in `checkMaxBetweenExclusiveImpl`) are **not** an msan problem — msan's bitwise shadow propagation correctly clears the masked-out bits, so those loops stay clean.
The actual blocker is the well-known msan requirement that **the whole program, including the C++ standard library, be instrumented**. With an uninstrumented libstdc++/libc++:
- The harness itself (`std::ifstream`/`std::stringstream` in `FuzzTestDriver.cpp`) immediately reports a false-positive use-of-uninitialized-value from `str.data()`, because the file read happens in uninstrumented library code. I confirmed this locally.
- Switching the harness to C I/O (`fread`, which msan intercepts) moves the report into the test driver's `std::set<std::string_view, ..., ArenaAlloc<...>>` usage in `TestDriver::next()` (Internal.h:~658) — `_Rb_tree::_M_get_insert_unique_pos` reading a node's `_M_left`. I couldn't determine whether that's a genuine uninitialized read or an msan/stdlib imprecision without an instrumented stdlib to compare against.
## What a working environment needs
The standard, documented way to run msan on C++ is to build an msan-instrumented `libc++`/`libc++abi`/`libunwind` from the LLVM source (e.g. via `runtimes` with `-DLLVM_USE_SANITIZER=Memory`) and build `msan_driver` against it (`-stdlib=libc++` + a sysroot/`-B` pointing at the instrumented libs). That's a non-trivial addition to the CI job — it needs the LLVM runtimes source and an extra build step — and I can't build/validate that instrumented-stdlib pipeline from this sandbox (no apt, can't clone llvm-project), so I don't want to ship an untested heavy CI job that would just go red.
## What I'd like to confirm
1. Is building an msan-instrumented `libc++` from LLVM source in CI (with the extra runtime cost) the approach you want, or do you have a preferred prebuilt msan sysroot / environment in mind?
2. Once that environment is in place, msan does surface a report in the test driver's `std::set` (Internal.h ~658). Are you expecting that to be a real bug to fix, or should I treat test-driver-only findings as out of scope and annotate/suppress them?
Once you point me at the preferred environment, I'll add the `USE_MSAN` CMake target + the CI job and follow up with a PR.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This could be a variant of fuzz_driver built with -fsanitize=memory if supported. We'll probably need to modify the ci script to get a working memory sanitizer environment going though
I looked into this and hit a real blocker around the sanitizer environment, so I'm pausing before opening a PR.
What I found
A
msan_drivervariant offuzz_driver(built fromConflictSet.cpp+FuzzTestDriver.cppwith-fsanitize=memory) compiles and links fine, and-fsanitize=memoryis supported by the clang we use in CI. The masked-but-unused reads that the code already annotates for valgrind (VALGRIND_MAKE_MEM_DEFINEDincheckMaxBetweenExclusiveImpl) are not an msan problem — msan's bitwise shadow propagation correctly clears the masked-out bits, so those loops stay clean.The actual blocker is the well-known msan requirement that the whole program, including the C++ standard library, be instrumented. With an uninstrumented libstdc++/libc++:
std::ifstream/std::stringstreaminFuzzTestDriver.cpp) immediately reports a false-positive use-of-uninitialized-value fromstr.data(), because the file read happens in uninstrumented library code. I confirmed this locally.fread, which msan intercepts) moves the report into the test driver'sstd::set<std::string_view, ..., ArenaAlloc<...>>usage inTestDriver::next()(Internal.h:~658) —_Rb_tree::_M_get_insert_unique_posreading a node's_M_left. I couldn't determine whether that's a genuine uninitialized read or an msan/stdlib imprecision without an instrumented stdlib to compare against.What a working environment needs
The standard, documented way to run msan on C++ is to build an msan-instrumented
libc++/libc++abi/libunwindfrom the LLVM source (e.g. viaruntimeswith-DLLVM_USE_SANITIZER=Memory) and buildmsan_driveragainst it (-stdlib=libc+++ a sysroot/-Bpointing at the instrumented libs). That's a non-trivial addition to the CI job — it needs the LLVM runtimes source and an extra build step — and I can't build/validate that instrumented-stdlib pipeline from this sandbox (no apt, can't clone llvm-project), so I don't want to ship an untested heavy CI job that would just go red.What I'd like to confirm
libc++from LLVM source in CI (with the extra runtime cost) the approach you want, or do you have a preferred prebuilt msan sysroot / environment in mind?std::set(Internal.h ~658). Are you expecting that to be a real bug to fix, or should I treat test-driver-only findings as out of scope and annotate/suppress them?Once you point me at the preferred environment, I'll add the
USE_MSANCMake target + the CI job and follow up with a PR.Use the msan-ci branch as a starting point