Findit identified the culprit r557680 with confidence 70.0% in the config "chromium.memory / Linux TSan Tests"
based on the flakiness trend:

https://findit-for-me.appspot.com/waterfall/flake?key=ag9zfmZpbmRpdC1mb3ItbWVyvwELEhdNYXN0ZXJGbGFrZUFuYWx5c2lzUm9vdCKIAWNocm9taXVtLm1lbW9yeS9MaW51eCBUU2FuIFRlc3RzLzIxNTQ0L2NvbnRlbnRfYnJvd3NlcnRlc3RzL1FuSnZkM05wYm1kRVlYUmhVbVZ0YjNabGNrbHRjR3hDY205M2MyVnlWR1Z6ZEM1UWNtVnpaWEoyWlVoMGRIQkJkWFJvUTJGamFHVT0MCxITTWFzdGVyRmxha2VBbmFseXNpcxgBDA


Automatically posted by the findit-for-me app (https://goo.gl/Ot9f7N).
Feedback is welcome! Please use component Tools>Test>FindIt>Flakiness

Will revert

Can you explanation how do you see "FindIt graph looks convincing"? In graph:
https://findit-for-me.appspot.com/waterfall/flake?key=ag9zfmZpbmRpdC1mb3ItbWVyywELEhdNYXN0ZXJGbGFrZUFuYWx5c2lzUm9vdCKUAWNocm9taXVtLm1lbW9yeS9MaW51eCBUU2FuIFRlc3RzLzIxNDQ4L2NvbnRlbnRfYnJvd3NlcnRlc3RzL1FuSnZkM05wYm1kRVlYUmhVbVZ0YjNabGNrbHRjR3hDY205M2MyVnlWR1Z6ZEM1UWNtVnpaWEoyWlZSeVlXNXpjRzl5ZEZObFkzVnlhWFI1VTNSaGRHVT0MCxITTWFzdGVyRmxha2VBbmFseXNpcxgBDA
The rate has dropped even before the revert with vision refs/heads/master@{#558668}.

Besides, I also checked the log of "Linux TSan Tests" (https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20TSan%20Tests?limit=500), this CL is in build 21390, and the first flaky is 21448. There are multiple failures between these two builds, but none of them is the flaky BrowsingDataRemoverImplBrowserTest test in the bug. WDYT? It is possible that the FindIt's result isn't correct.

The revert (r558668) has landed, so let me remove this bug from the sheriffing queue.  OTOH, I am not sure if I understand what is going on here:

- The flakiness dashboard [1] seems to show stale results (up till r519748).  Maybe I am holding it wrong?

- The try-flakes doesn't have any entries [2,3] for this test


[1] https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=content_browsertests&tests=BrowsingDataRemoverImplBrowserTest.PreserveHttpAuthCache

[2] https://chromium-try-flakes.appspot.com/search?q=BrowsingDataRemoverImplBrowserTest

[3] https://chromium-try-flakes.appspot.com/search?q=PreserveHttpAuthCache

I don’t know enough about FindIt to answer those questions. Moving to the FindIt queue in search of someone who can.

According to https://chromium-review.googlesource.com/c/chromium/src/+/1059167#message-1fc61c4e2d4ee54e0c0cab9b660384bc3c755481, Findit's finding is correct in this case.

Marking the analysis as incorrect won't trigger a new analysis of the same test.
lijeffrey@ is working on a feature to verify whether the test is still flaky at the latest build on Waterfall or a given commit.

If you have feedback on how to make the analysis result easier to interpret or anything else, please feel free to file bug or feature request and assign component Tools>Test>FindIt>Flakiness.

I checked the failed bot "Linux Tsan Testers" again, and it seems this test only failed once. Besides, I can't repro it locally, with tsan target and repeating the tests multiple times. I also tried to let the main thread sleeps 1000 milliseconds, which allows the io thread reads the a variable before the variable's value is reset in the main thread, the same race condition doesn't occur. I doubt the FindIt result isn't correct.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/534c9fe47c05a3abeb8746db301cfecdbf9da404

commit 534c9fe47c05a3abeb8746db301cfecdbf9da404
Author: Xi Han <hanxi@google.com>
Date: Tue May 22 14:40:29 2018

Fix a data race in startup.

The data race was found in:
https://logs.chromium.org/v/?s=chromium%2Fbuildbucket%2Fcr-buildbucket.appspot.com%2F8946759693378483472%2F%2B%2Fsteps%2Fcontent_browsertests%2F0%2Flogs%2FBrowsingDataRemoverImplBrowserTest.PreserveTransportSecurityState%2F0

The BrowserThread::IO is created in CreateThreads(). After that,
ServiceManagerContext will call GetNetworkService() which will access
ContetBrowserClient::GetNetLog() on BrowserThread::IO. In content_browsertests,
the |net_log| is created in ShellBrowserMainParts, while instantiated in the
ShellBrowserMainParts::PreMainMessageLoopRun() which is after the CreateThreads().
The data race happens when the |net_log| is accessed on the BrowserThread::IO
while it is instantiated on the main thread.

To fix this race, we instantiate the value of |net_log| in PreCreateThreads().

Bug:  843003 
Change-Id: I3e45ac9eae0d9edc37fddbd1396cd56226a8abde
Reviewed-on: https://chromium-review.googlesource.com/1064450
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Commit-Queue: Xi Han <hanxi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560574}
[modify] https://crrev.com/534c9fe47c05a3abeb8746db301cfecdbf9da404/content/shell/browser/shell_browser_main_parts.cc