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
This commit is contained in:
Abseil Team 2023-12-18 10:14:04 -08:00 committed by Copybara-Service
parent 530d5c8c84
commit 8495449f07

View File

@ -490,6 +490,7 @@ class MockObjectRegistry {
// failure, unless the user explicitly asked us to ignore it. // failure, unless the user explicitly asked us to ignore it.
~MockObjectRegistry() { ~MockObjectRegistry() {
if (!GMOCK_FLAG_GET(catch_leaked_mocks)) return; if (!GMOCK_FLAG_GET(catch_leaked_mocks)) return;
internal::MutexLock l(&internal::g_gmock_mutex);
int leaked_count = 0; int leaked_count = 0;
for (StateMap::const_iterator it = states_.begin(); it != states_.end(); for (StateMap::const_iterator it = states_.begin(); it != states_.end();