Assigning to the concern owner from Find it results --
The result is a list of CLs that change the crashed files. 

Author: haraken
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/e92a9ecd9576c66288a2fd403ec9ae1e363a59cb
Time: Fri Jan 13 18:18:54 2017
File ThreadState.cpp is changed in this cl (and is part of stack frame #3, "blink::ThreadState::performIdleLazySweep")
Minimum distance from crash line to modified line: 91. (file: ThreadState.cpp, crashed on: 853, modified: 944).

@haraken -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

This looks related to the per-thread heap, but it looks strange that we race on blink::NormalPage::sweep(). NormalPage should be completely isolated per thread.

WARNING: ThreadSanitizer: data race (pid=21185)
Write of size 8 at 0x7ee8edd66930 by main thread:
#0 0x7fe6d579067a in memset (/mnt/scratch0/clusterfuzz/slave-bot/builds/chromium-browser-tsan_linux-release_e1f0dbf462d779d5196ef318a224a998657a9c66/revisions/tsan-linux-release-443650/chrome+0xbfb679)
#1 0x7fe6d7585d8a in blink::NormalPage::sweep() third_party/WebKit/Source/platform/heap/HeapPage.cpp:1392:7
#2 0x7fe6d7582431 in blink::BaseArena::lazySweepWithDeadline(double) third_party/WebKit/Source/platform/heap/HeapPage.cpp:307:11
#3 0x7fe6d758e7ba in blink::ThreadState::performIdleLazySweep(double) third_party/WebKit/Source/platform/heap/ThreadState.cpp:828:25
#4 0x7fe6d7593e67 in base::internal::Invoker<base::internal::BindState<void (blink::ThreadState::*)(double), WTF::UnretainedWrapper<blink::ThreadState, (WTF::FunctionThreadAffinity)1> >, void (double)>::Run(base::internal::BindStateBase*, double&&) base/bind_internal.h:214:12
#5 0x7fe6daae1bb1 in blink::(anonymous namespace)::IdleTaskRunner::run(double) base/callback.h:85:12

Previous read of size 8 at 0x7ee8edd66930 by thread T13:
[failed to restore the stack]
Thread T13 WebCore: Database (tid=21272, running) created by main thread at:
#0 0x7fe6d5787536 in pthread_create (/mnt/scratch0/clusterfuzz/slave-bot/builds/chromium-browser-tsan_linux-release_e1f0dbf462d779d5196ef318a224a998657a9c66/revisions/tsan-linux-release-443650/chrome+0xbf2535)
#1 0x7fe6d7d03498 in base::(anonymous namespace)::CreateThread(unsigned long, bool, base::PlatformThread::Delegate*, base::PlatformThreadHandle*, base::ThreadPriority) base/threading/platform_thread_posix.cc:110:13

Oh, is this showing up issue 672425 with a testcase?

keishi@: Would you check if the TSan crash reproduces with the attached test case?

I was able to reproduce the crash and I found the issue.
https://codereview.chromium.org/2631403002/

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

commit 7c916610d4392731e6520d2bfd60c674303bb7a9
Author: keishi <keishi@chromium.org>
Date: Fri Feb 10 05:24:12 2017

CrossThreadPersistent should acquire a lock before assigning

The root set in CrossThreadPersistent should not change while a thread is trying to mark as it may cause objects unmarked when it should be marked.

This acquires a lock before assigning a new pointer to a CrossThreadPersistent node.

BUG= 681488 

Review-Url: https://codereview.chromium.org/2660463003
Cr-Commit-Position: refs/heads/master@{#449548}

[modify] https://crrev.com/7c916610d4392731e6520d2bfd60c674303bb7a9/third_party/WebKit/Source/platform/heap/Persistent.h

ClusterFuzz has detected this issue as fixed in range 449378:449549.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5846834347245568

Fuzzer: inferno_twister
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race WRITE 8
Crash Address: 0x7ee8edd66930
Crash State:
  blink::NormalPage::sweep
  blink::BaseArena::lazySweepWithDeadline
  blink::ThreadState::performIdleLazySweep
  
Sanitizer: thread (TSAN)

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=443594:443650
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=449378:449549

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv97_VcNz7FSvR5ZV_A5X35qJyu1yq6qiFabq9MXF_aYjnqt0o3Dk_eDKBW8BDH8inLOXmV4LeRb4ymXAY7SOejxD9N6TVV1McgOaboXCOCPG7ByNXuC0rPd65efSfK3Fn4mtxzjqlb2j0CKlTMjjmAfhyxIOILyS2Yi5ffCEELvtHRSE8c1Y02YxEBGehxgBv77CWM83QBJFrIfQKn39TWO1Dt7kJRUwBTmFM43XUTc40ilhhxpyGvxVJ0qgUoD2wDwYZ6mYqAhLSvbgx4eeFwmD5mT-sFWGJx93XwZFw6Pzs2pANqFjHAaNxcCtMuqyIsH2ZOYv_FVc6djvf-IFKN4SsIO8R0GgHYmr3L3r3uJ0Dvb2i7Y?testcase_id=5846834347245568


Additional requirements: Requires HTTP

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5846834347245568 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.