thakis@, thanks for dealing with the flakiness and disabling the tests.
I have difficulties parsing the stack trace. I see threads T24 and T25 writing stuff to SQLite. They *should* each write to a different SQLite instance (History vs WebDB).
I see both of them starting with "Write of size 4 at 0x55a8a3c59040." What does this address refer to?
(cc'ing treib@ and feuunk@ who might also be remotely related with this bug by a recent refactoring in WebDataServiceWrapper)
For the address, see the later line:
Location is global 'pcache1Create.dummyCurrentPage' of size 4 at 0x55a8a3c59040 (sync_integration_tests+0x00000f50b040)
Let me put on my concurrency hat and remind you there's no such thing as "innocent" data race (there's a wonderful article, "How to miscompile programs with “benign” data races", exactly on this matter). This is still UB from the C++ point of view, so we'd better fix such bugs unless we have strong reasons not to.
In this particular case I don't see the value of dummyCurrentPage being used anywhere, so the question is whether we need it at all.
Cc: pwnall@chromium.org Summary: ThreadSanitizer complains about data race in sqlite (when multiple sqlite instances are used from multiple threads) (was: SingleClientWalletSecondaryAccountSyncTest.SwitchesFromAccountToProfileStorageOnSyncOptIn is flaky)
This should be fixed on sqlite trunk by https://www.sqlite.org/src/info/383437be276719ac.
pwnall@, do you think you could back-port that CL into sqlite in chromium?
(if you cannot make it, please let me know so that it does not wait unresolved for too long; it is causing quite some TSan flakiness)
pwnall@, thanks a million! I've briefly checked and haven't seen the sqlite issue happen again.
Since another cause of TSan flakiness in sync_integration_tests ( Issue 915219 ) has been fixed only an hour ago, I'll wait some time to see TSan is happy.
Then I re-enable all the disabled tests.
Comment 1 by thakis@chromium.org
, Dec 21