Simply compile and link your program with -fsanitize=memory flag.
The MemorySanitizer run-time library should be linked to the final
executable, so make sure to use clang (not ld) for the final
link step. When linking shared libraries, the MemorySanitizer run-time
is not linked, so -Wl,-z,defs may cause link errors (don’t use it
with MemorySanitizer). To get a reasonable performance add -O1 or
higher. To get meaninful stack traces in error messages add
-fno-omit-frame-pointer. To get perfect stack traces you may need
to disable inlining (just use -O1) and tail call elimination
(-fno-optimize-sibling-calls).

If a bug is detected, the program will print an error message to
stderr and exit with a non-zero exit code. Currently, MemorySanitizer
does not symbolize its output by default, so you may need to use a
separate script to symbolize the result offline (this will be fixed in
future).

Some code should not be checked by MemorySanitizer.
One may use the function attribute
no_sanitize_memory
to disable uninitialized checks in a particular function.
MemorySanitizer may still instrument such functions to avoid false positives.
This attribute may not be
supported by other compilers, so we suggest to use it together with
__has_feature(memory_sanitizer).

MemorySanitizer supports src and fun entity types in
Sanitizer special case list, that can be used to relax MemorySanitizer
checks for certain source files and functions. All “Use of uninitialized value”
warnings will be suppressed and all values loaded from memory will be
considered fully initialized.

MemorySanitizer uses an external symbolizer to print files and line numbers in
reports. Make sure that llvm-symbolizer binary is in PATH,
or set environment variable MSAN_SYMBOLIZER_PATH to point to it.

MemorySanitizer can track origins of unitialized values, similar to
Valgrind’s –track-origins option. This feature is enabled by
-fsanitize-memory-track-origins Clang option. With the code from
the example above,

MemorySanitizer requires that all program code is instrumented. This
also includes any libraries that the program depends on, even libc.
Failing to achieve this may result in false reports.

Full MemorySanitizer instrumentation is very difficult to achieve. To
make it easier, MemorySanitizer runtime library includes 70+
interceptors for the most common libc functions. They make it possible
to run MemorySanitizer-instrumented programs linked with
uninstrumented libc. For example, the authors were able to bootstrap
MemorySanitizer-instrumented Clang compiler by linking it with
self-built instrumented libcxx (as a replacement for libstdc++).

In the case when rebuilding all program dependencies with
MemorySanitizer is problematic, an experimental MSanDR tool can be
used. It is a DynamoRio-based tool that uses dynamic instrumentation
to avoid false positives due to uninstrumented code. The tool simply
marks memory from instrumented libraries as fully initialized. See
http://code.google.com/p/memory-sanitizer/wiki/Running#Running_with_the_dynamic_tool
for more information.

MemorySanitizer maps (but not reserves) 64 Terabytes of virtual
address space. This means that tools like ulimit may not work as
usually expected.

Static linking is not supported.

Non-position-independent executables are not supported. Therefore, the
fsanitize=memory flag will cause Clang to act as though the -fPIE
flag had been supplied if compiling without -fPIC, and as though the
-pie flag had been supplied if linking an executable.

Depending on the version of Linux kernel, running without ASLR may
be not supported. Note that GDB disables ASLR by default. To debug
instrumented programs, use “set disable-randomization off”.