From 8495449f075543dbac005d6c33118e58ad770d75 Mon Sep 17 00:00:00 2001 From: Abseil Team Date: Mon, 18 Dec 2023 10:14:04 -0800 Subject: [PATCH] Fix data race in leak detection TSAN identified a data race between updates to the states_ map (ex. in Mock::UnregisterLocked) and the iteration done in this destructor. Writes to the map use g_gmock_mutex, but the destructor does not acquire it. Acquiring the lock here fixes the data race. It should only be possible to trigger this TSAN finding in cases where a mock object is deleted by a thread other than the main thread. PiperOrigin-RevId: 591935393 Change-Id: I9dd1faa40058d78e165a91333346514b4b73365c --- googlemock/src/gmock-spec-builders.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/googlemock/src/gmock-spec-builders.cc b/googlemock/src/gmock-spec-builders.cc index de894716..fb67ab09 100644 --- a/googlemock/src/gmock-spec-builders.cc +++ b/googlemock/src/gmock-spec-builders.cc @@ -490,6 +490,7 @@ class MockObjectRegistry { // failure, unless the user explicitly asked us to ignore it. ~MockObjectRegistry() { if (!GMOCK_FLAG_GET(catch_leaked_mocks)) return; + internal::MutexLock l(&internal::g_gmock_mutex); int leaked_count = 0; for (StateMap::const_iterator it = states_.begin(); it != states_.end();