MemorySanitizer (MSan) is a tool that detects use of uninitialized memory.
MSan is supported on x86_64 Linux. Additional info on the tool is available at http://clang.llvm.org/docs/MemorySanitizer.html.
MSan in Chromium is unlikely to be usable on systems other than Ubuntu Precise/Trusty - please see the note on instrumented libraries below.
MSan bots are running on chromium.memory.fyi, client.webrtc and chromium.webkit. There are also two LKGR builders for ClusterFuzz: no origins, chained origins (see below for explanation). V8 deployment is ongoing.
To set up an MSan build in GN (setting GYP_DEFINES and running gclient are necessary the first time to make it download the instrumented libraries ☹):
gn args out/msan
In the resulting editor, set the build variables:
Instrumented libraries are enabled with a separate flag because certain smaller targets do not need them. This applies to targets such as
Note that instrumented libraries are supported on Ubuntu Precise/Trusty only. More information: instrumented-libraries-for-dynamic-tools.
The following flags are implied by
Run the resulting binaries as usual. Pipe the output through
Chrome must not use hardware OpenGL when running under MSan. This is because libgl.so is not instrumented and will crash the GPU process. OSMesa can be used as a software OpenGL implementation, although it is extremely slow. There are several ways to proceed:
If neither flag is specified, Chrome will fall back to the first option after the GPU process crashes with an MSan report.
MSan allows the user to trade off execution speed for the amount of information provided in reports. This is controlled by the GN/GYP flag
MSan does not support suppressions. This is an intentional design choice.
We have a blacklist file which is applied at compile time, and is used mainly to compensate for tool issues. Blacklist rules do not work the way suppression rules do - rather than suppressing reports with matching stack traces, they change the way MSan instrumentation is applied to the matched function. In addition, blacklist changes require a full clobber to take efffect. Please refrain from making changes to the blacklist file unless you know what you are doing.
Note also that instrumented libraries use separate blacklist files.
MSan reserves a separate memory region ("shadow memory") in which it tracks the status of application memory. The correspondence between the two is bit-to-bit: if the shadow bit is set to 1, the corresponding bit in the application memory is considered "poisoned" (i.e. uninitialized). The header file
Print the complete shadow state of a range of application memory, including the origins of all uninitialized values, if any. (Note: though initializedness is tracked on bit level, origins have 4-byte granularity.)
The following prints a more minimalistic report which shows only the shadow memory:
To mark a memory range as fully uninitialized/initialized:
The following forces an MSan check, i.e. if any bits in the memory range are uninitialized the call will crash with an MSan report.
This milder check returns the offset of the first (at least partially) poisoned byte in the range, or -1 if the whole range is good:
Hint: sometimes to reduce log spam it makes sense to query
The complete interface can be found in