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

MSan is currently undergoing Chromium deployment. We have experimental bots running on builder, tester, browser tests. There are also two LKGR bots: no origins, chained origins (see below for explanation).

Using MSan

A note on V8: If you're trying to debug a V8-related issue, please keep in mind that MSan builds run V8 in ARM64 mode, as explained below.

Before building, you may need to install build dependencies for instrumented libraries (see below to find out if you actually need them):

sudo third_party/instrumented_libraries/

Goobuntu users will also need to enable source repos:

sudo goobuntu-config set include_deb_src true

This is how we currently build:

GYP_DEFINES='use_goma=1 msan=1 use_instrumented_libraries=1 instrumented_libraries_jobs=20' gclient runhooks
ninja -C out/Release base_unittests

Flags breakdown:
  • msan=1: Enable MSan support in Chromium binaries.
  • use_instrumented_libraries=1: DSOs which Chrome depends on will be rebuilt from source with MSan instrumentation. Without this flag MSan will produce lots of false positive reports, making it unusable. This flag is EXPERIMENTAL. Additionally, it's not currently guaranteed to work correctly on systems other than 12.04 Ubuntu.
  • instrumented_libraries_jobs=20: Use multiple parallel jobs when building instrumented libraries. This specifies the number of jobs to be spawned per package, so the total number of jobs will be much higher. If you're not using goma, it's probably best to omit this flag.
Instrumented libraries are enabled with a separate flag because certain smaller targets do not need them. This applies to targets such as pdfium_test and d8. I.e., when building those targets you may, but do not have to, set this flag. Larger targets like Chrome and most chromium test binaries will definitely require it.
Note that setting this flag will add a number (<100) of extra steps to the build. These steps will have names such as msan-<package_name> and each of them will build an entire instrumented package, thus they are expected to take much longer than other steps. The build should still take a reasonable time though (perhaps 20 minutes longer than a regular build).

The following flags are implied by msan=1 (i.e. you don't have to set them explicitly):
  • use_custom_libcxx=1Use a just-built, MSan-instrumented libc++ instead of the system-wide libstdc++. This is required to avoid false positive reports whenever the C++ standard library is used. (Note: occasionally we encounter non-standard-compliant code which behaves differently in libc++ builds vs regular builds. Such code should be fixed.)
  • 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 positive reports.
Run the resulting binaries as usual. Pipe the output through tools/valgrind/asan/ to get symbolized reports.
When running browser tests, Chrome or content shell, you need to also pass --use-gl=osmesa, otherwise you will see crashes in

Origin tracking

MSan allows the user to trade off execution speed for the amount of information provided in reports. This is controlled by the GYP flag msan_track_origins:
  • msan_track_origins=0 - MSan will tell you where the uninitialized value was used, but not where it came from. This is the fastest mode.
  • msan_track_origins=1 (default) - MSan will also tell you where the uninitialized value was originally allocated (e.g. which malloc() call, or which local variable).
  • msan_track_origins=2 - MSan will also report the chain of stores that copied the uninitialized value to its final location. If there are more than 7 stores in the chain, only the first 7 will be reported. This mode is EXPERIMENTAL. Note also that compilation time may increase in this mode.