MemorySanitizer (MSan) is a detector of uninitialized reads based on compiler instrumentation (LLVM).
It is EXPERIMENTAL. The only supported platform is Linux64.
Additional info on the tool itself is available at Some information is available from MSan wiki.

MSan is currently undergoing Chromium deployment. We have an experimental bot running at

Using MSan

This is how we currently build:

GYP_GENERATORS=ninja GYP_DEFINES='msan=1 use_allocator=none use_instrumented_libraries=1 instrumented_libraries_jobs=20 use_custom_libcxx=1 v8_target_arch=arm64' gclient runhooks
ninja -C out/Release base_unittests

Flags breakdown:
  • msan=1: Enable basic MSan support.
  • use_custom_libcxx=1: Use libc++ instead of libstdc++ as the C++ standard library implementation. This allows us to rebuild the C++ standard library from source with MSan instrumentation. Without this flag, any use of the standard library may cause an error report from MSan. This flag is EXPERIMENTAL.
  • use_instrumented_libraries=1: DSOs which Chrome depends on will be rebuilt from source with MSan instrumentation. Again, without this flag MSan will report a lot of false positives. This flag is EXPERIMENTAL.
  • instrumented_libraries_jobs=20: Use multiple parallel jobs when building instrumented libraries.
  • v8_target_arch=arm64: JavaScript code will be compiled for ARM64 and run on an ARM64 simulator. This allows MSan to instrument JS code. Without this flag there will be false positives.
Run the resulting binaries as usual. Be sure to have third-party/llvm-build/Release+Assers/bin in PATH to get symbolized reports.

Running tests with MSanDR

WARNING: the information below may be out of date.

MSan can be used with a helper tool called MSanDR to avoid false positives from uninstrumented system libraries.
Add the following to custom_deps section of .gclient:


Run the tests:

src/third_party/msandr/ out/Release/base_unittests

Native exec

Native_exec is a special mode of MSanDR where compiler-instrumented modules are not dynamically translated. Instead DR transfers control to compiler-instrumented code directly, patches PLT entries and expects some help from the compiler to catch returns via indirect jumps.

Some information on this mode is available at

A hacky way to build unit tests with native_exec support is with the following CFLAGS (change /code/llvm to your path to the msandr client):
-mllvm -msan-wrap-indirect-calls=dr_app_handle_mbr_target -Wl,--undefined=dr_app_handle_mbr_target -w -L/code/llvm/projects/compiler-rt/lib/msandr/dr/exports/lib64/release -ldynamorio