Don't run ThreadLocalStorageTest.TLSDestructors under ThreadSanitizer v2.

This test causes false race reports because of TSan failing to synchronize the TSD destructor after the max possible number of iterations with another user of the same TSD slot.

BUG=128314,thread-sanitizer:7
TBR=jam
Review URL: https://codereview.chromium.org/11503014

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@172062 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 11 insertions, 1 deletions

diff --git a/base/threading/thread_local_storage_unittest.cc b/base/threading/thread_local_storage_unittest.cc
index 8e222ee..e295c89 100644
--- a/base/threading/thread_local_storage_unittest.cc
+++ b/base/threading/thread_local_storage_unittest.cc
@@ -79,7 +79,17 @@ TEST(ThreadLocalStorageTest, Basics) {
   EXPECT_EQ(value, 123);
 }
 
-TEST(ThreadLocalStorageTest, TLSDestructors) {
+#if defined(THREAD_SANITIZER)
+// Do not run the test under ThreadSanitizer. Because this test iterates its
+// own TSD destructor for the maximum possible number of times, TSan can't jump
+// in after the last destructor invocation, therefore the destructor remains
+// unsynchronized with the following users of the same TSD slot. This results
+// in race reports between the destructor and functions in other tests.
+#define MAYBE_TLSDestructors DISABLED_TLSDestructors
+#else
+#define MAYBE_TLSDestructors TLSDestructors
+#endif
+TEST(ThreadLocalStorageTest, MAYBE_TLSDestructors) {
   // Create a TLS index with a destructor.  Create a set of
   // threads that set the TLS, while the destructor cleans it up.
   // After the threads finish, verify that the value is cleaned up.