diff options
| author | Abseil Team <absl-team@google.com> | 2023-12-18 10:14:04 -0800 |
|---|---|---|
| committer | Copybara-Service <copybara-worker@google.com> | 2023-12-18 10:14:49 -0800 |
| commit | 8495449f075543dbac005d6c33118e58ad770d75 (patch) | |
| tree | 8d0270cf082cb44b7ffb84b2a050755611ebf8e8 | |
| parent | 530d5c8c84abd2a46f38583ee817743c9b3a42b4 (diff) | |
| download | googletest-8495449f075543dbac005d6c33118e58ad770d75.tar.gz | |
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
| -rw-r--r-- | googlemock/src/gmock-spec-builders.cc | 1 |
1 files changed, 1 insertions, 0 deletions
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(); |