I'm in the blamelist for https://uberchromegw.corp.google.com/i/chromium.memory/builders/Linux%20TSan%20Tests/builds/7645

I'll check.

So the race happens inside gTest library:

testing::internal::UntypedFunctionMockerBase::UntypedInvokeWith() calls untyped_expectations_.size()

and FunctionMockerBase::AddNewExpectation() calls untyped_expectations_.push_back()

and they are not synchronized.

I think there is a bug in MemoryDumpSchedulerTest.StopAndStartOnAnotherThread test: in the second part ("MemoryDumpSchedulerTest Thread 2") it should first call EXPECT_CALL() (which calls AddNewExpectation) and then call scheduler_->Start().

What happens how is scheduler_->Start() posts two tasks which in the end invoke CallbackWrapper::OnTick mock method *before* the main thread gets to EXPECT_CALL() statements.

ssid@, primiano@ do you think my analysis is correct?

I'm still trying to understand how my CL (or any CL from the blamelist) could trigger that...

Aha! The test is just flaky, https://uberchromegw.corp.google.com/i/chromium.memory/builders/Linux%20TSan%20Tests/builds/7647 succeeded.

ssid@, can you take this, and submit a fix?

Yup, the test is flaky, here is similar failure from the past (Jun 16): https://uberchromegw.corp.google.com/i/chromium.memory/builders/Linux%20TSan%20Tests/builds/7558

Good find! This test is indeed flaky and became so recently. Here's a link to the test history:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=base_unittests&tests=MemoryDumpSchedulerTest.StopAndStartOnAnotherThread%0A

The fix is easy, I'm going to land it instead of disabling the test.

https://codereview.chromium.org/2952493002 is in the commit queue.

Re #3: the analysis in #3 makes perfect sense, so does your fix #8.
I wished there was a way to preemptively warn for these patterns that end up causing test flakiness.

Marking as fixed as the flakiness seems to have gone. Reopen if it's not the case.