ThreadSanitizer v2 is a compiler-based version of ThreadSanitizer with a brand new state machine. It is only supported on Linux so far and has nothing to do with Valgrind.
Note: TSan has its own allocator, therefore we have to disable TCMalloc.
Note 2: due to http://crbug.com/324489 we have to build the tests with Aura.
export PATH="$PATH:$PWD/third_party/llvm-build/Release+Asserts/bin/" # work around crbug.com/310479
TSAN_OPTIONS="external_symbolizer_path=third_party/llvm-build/Release+Asserts/bin/llvm-symbolizer suppressions=tools/valgrind/tsan_v2/suppressions.txt report_signal_unsafe=0 report_thread_leaks=0 print_suppressions=1" out/Release/base_unittests --no-sandbox 2>&1 | tee log
atexit_sleep_ms is 1 second by default. Some tests waiting for child processes may fail with such a big timeout.
Tests with big memory footprint may hang your machine, so you need to flush periodically (flush_memory_ms) and skip heavy tests (like OOM)
flush_memory_ms may lead to false negatives, thus the flushing period should be chosen carefully.
If TSan fails to restore one of the stacks, try adding history_size=7 to TSAN_OPTIONS (the amount of memory reserved for the stacks is proportional to 2^history_size, 7 is the maximum value).
Note: --no-sandbox is essential if you're running Chrome or tests that invoke Chrome (browser_tests, content_browsertests etc.)
Note 2: due to http://crbug.com/341805 you may need to run Chrome with --disable-gpu or use xvfb-run.
Note 3: always run with --child-clean-exit. Running the test multiple times in a row (--gtest_repeat=5) may increase the reproducibility of the races.
LKGR bot building Chromium with TSan: https://commondatastorage.googleapis.com/chromium-browser-tsan/index.html
ThreadSanitizer v2 suppressions reside in tools/valgrind/tsan_v2/suppressions.txt
ThreadSanitizer data race report contains two or more stack traces of conflicting memory accesses (the topmost access is the last one) together with the thread IDs and the acquired mutexes.
For a global variable involved its name is printed, stack or heap memory locations are described using the allocation stack trace.
When applicable, the stack traces of thread creations and mutex acquisitions are also listed.
Each suppression is a one line of the form "suppression_type:pattern". The most common suppression type is "race", see https://code.google.com/p/thread-sanitizer/wiki/Suppressions for other suppression types.
The pattern is matched against:
'*' is automatically prepended to each pattern unless it starts with '^'.
'*' is automatically appended to each pattern unless it ends with '$'.
Good suppressions match a single race report (or a number of reports with a common root cause), but are unlikely to mask further races in other components.
A suppression must be preceded by a comment (started with a "#") with a crbug link.
Examples of good suppressions for the above race report:
Examples of bad suppressions:
More info on the suppressions format is available at https://code.google.com/p/thread-sanitizer/wiki/Suppressions.
Before trying to reproduce a race report in a Chromium test, make sure they are not suppressed or ignored.
Suppressions from tools/valgrind/tsan_v2/suppressions.txt are applied at program runtime. If the race report matches a line in the suppressions file, TSan does not print that report.
Ignores from tools/valgrind/tsan_v2/ignores.txt are applied at compile time. If the function name matches a "fun:" line in the ignores file, TSan does not instrument that function, effectively ignoring all memory accesses (but not synchronization) in that function. If the source file name matches an "src:" line, every function in that file is ignored. Note that the tests do not depend on ignores.txt, so you need to touch all the affected source files manually before rebuilding (or make a clean build) after any change to
You can't execute an instrumented binary from GDB, because it maps something in the place where TSan needs to map its shadow:
However you can attach GDB to a running TSan process. If you have troubles catching a particular process, try to run with
Every subprocess will print the following line:
In order to proceed, you'll have to run