Unable to find the exact culprit, hence looping https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/modules/OWNERS

Thank you!

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

Fuzzer: inferno_flicker
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race READ 8
Crash Address: 0x7d040001f730
Crash State:
  blink::AudioListener::updateState
  blink::AbstractAudioContext::handlePreRenderTasks
  blink::AudioDestinationHandler::render
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=393907:394251

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv9678mzyh7i8rOfdqCBQMT7CmhpfV_rR2k5o0VeuhVz3yL7CAWvGbFk5OJMHJyrKK0yas8Vm1BgxCHKeK3W5XLooXPkSnoruJzHSyv5RrcCXZHiIAbdRD4HOsCjwkr7E_1-HvgfFhTWS3OiogIN6vO4XMrFkBdZKh__uNqmq0ECu4607Rxk


Filer: manoranjanr

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

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

commit a6beb9f31fba1c7892fbfb4911f34e5a13492183
Author: rtoy <rtoy@chromium.org>
Date: Tue May 24 23:48:06 2016

Simplify notification of a dirty listener.

Instead of the listener updating the dirty state of all panners, just
set a dirty state flag in the listener.  Then, when a panner needs
to compute a new azimuth/elevation gain or cone gain, the panner
just checks to see if the listener is dirty.

This gets rid of the data race where both the audio thread and the
main thread are updating the dirty state of a panner.  The checking
and setting of the listener state happens on the audio thread.

The race from reading from the hash table of panners in AudioListener
and adding to the table from the main thread is also removed.

BUG= 612948 ,  612955 ,  613332 
TEST=none

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

[modify] https://crrev.com/a6beb9f31fba1c7892fbfb4911f34e5a13492183/third_party/WebKit/Source/modules/webaudio/AudioListener.cpp
[modify] https://crrev.com/a6beb9f31fba1c7892fbfb4911f34e5a13492183/third_party/WebKit/Source/modules/webaudio/AudioListener.h
[modify] https://crrev.com/a6beb9f31fba1c7892fbfb4911f34e5a13492183/third_party/WebKit/Source/modules/webaudio/PannerNode.cpp
[modify] https://crrev.com/a6beb9f31fba1c7892fbfb4911f34e5a13492183/third_party/WebKit/Source/modules/webaudio/PannerNode.h

ClusterFuzz has detected this issue as fixed in range 395707:395767.

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

Fuzzer: inferno_flicker
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race READ 8
Crash Address: 0x7d040001f730
Crash State:
  blink::AudioListener::updateState
  blink::AbstractAudioContext::handlePreRenderTasks
  blink::AudioDestinationHandler::render
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=393907:394251
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=395707:395767

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv9678mzyh7i8rOfdqCBQMT7CmhpfV_rR2k5o0VeuhVz3yL7CAWvGbFk5OJMHJyrKK0yas8Vm1BgxCHKeK3W5XLooXPkSnoruJzHSyv5RrcCXZHiIAbdRD4HOsCjwkr7E_1-HvgfFhTWS3OiogIN6vO4XMrFkBdZKh__uNqmq0ECu4607Rxk


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.

The new crash stack for c#1 shows that the original crash is gone, however there is a new issue with a data race between sumAllConnections and setChannelInterpretation.

Based on this, and c#5, I think the original issue is fixed.  It would be good to get a new issue for the new data race.

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

commit 84ecd66b39c24e7614412f08571b98380d7cd41d
Author: Raymond Toy <rtoy@chromium.org>
Date: Thu May 26 17:16:31 2016

Simplify notification of a dirty listener.

Instead of the listener updating the dirty state of all panners, just
set a dirty state flag in the listener.  Then, when a panner needs
to compute a new azimuth/elevation gain or cone gain, the panner
just checks to see if the listener is dirty.

This gets rid of the data race where both the audio thread and the
main thread are updating the dirty state of a panner.  The checking
and setting of the listener state happens on the audio thread.

The race from reading from the hash table of panners in AudioListener
and adding to the table from the main thread is also removed.

BUG= 612948 ,  612955 ,  613332 
TEST=none

Review-Url: https://codereview.chromium.org/2006563003
Cr-Commit-Position: refs/heads/master@{#395738}
(cherry picked from commit a6beb9f31fba1c7892fbfb4911f34e5a13492183)

Review URL: https://codereview.chromium.org/2012773005 .

Cr-Commit-Position: refs/branch-heads/2743@{#78}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/84ecd66b39c24e7614412f08571b98380d7cd41d/third_party/WebKit/Source/modules/webaudio/AudioListener.cpp
[modify] https://crrev.com/84ecd66b39c24e7614412f08571b98380d7cd41d/third_party/WebKit/Source/modules/webaudio/AudioListener.h
[modify] https://crrev.com/84ecd66b39c24e7614412f08571b98380d7cd41d/third_party/WebKit/Source/modules/webaudio/PannerNode.cpp
[modify] https://crrev.com/84ecd66b39c24e7614412f08571b98380d7cd41d/third_party/WebKit/Source/modules/webaudio/PannerNode.h

Filed issue 615093 for the new race.

Closing as fixed since clusterfuzz says the other cases are fixed.

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

commit dd2bffb1f8812c26400a2aca38f1eb9c1fced985
Author: rtoy <rtoy@chromium.org>
Date: Thu May 26 23:34:16 2016

Defer changes to channelInterpretation to pre/post rendering.

If the main thread changes the channel interpretation, record the
change and do the update to the channel interpretation in the pre and/or
post rendering phase in the deferred task handler.

This removes the race in setting the interpretation in the main thread
while also reading it in the audio thread which uses the
interpretation to determine how to sum a bunch of connections
together.

BUG=615093,  613332 
TEST=none

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

[modify] https://crrev.com/dd2bffb1f8812c26400a2aca38f1eb9c1fced985/third_party/WebKit/Source/modules/webaudio/AbstractAudioContext.h
[modify] https://crrev.com/dd2bffb1f8812c26400a2aca38f1eb9c1fced985/third_party/WebKit/Source/modules/webaudio/AudioNode.cpp
[modify] https://crrev.com/dd2bffb1f8812c26400a2aca38f1eb9c1fced985/third_party/WebKit/Source/modules/webaudio/AudioNode.h
[modify] https://crrev.com/dd2bffb1f8812c26400a2aca38f1eb9c1fced985/third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.cpp
[modify] https://crrev.com/dd2bffb1f8812c26400a2aca38f1eb9c1fced985/third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.h

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

commit c117666ede47a2ee7c7e403ef43b3718b9d7c716
Author: Nico Weber <thakis@chromium.org>
Date: Fri May 27 14:24:09 2016

Unbreak release component builds on Windows after https://codereview.chromium.org/2014343002/

DCHECK expands to

#define DCHECK(condition)                                                \
  LAZY_STREAM(LOG_STREAM(DCHECK), DCHECK_IS_ON() ? !(condition) : false) \
      << "Check failed: " #condition ". "

which requires calls in condition to exist even in non-dcheck builds,
they're just stripped later because DCHECK_IS_ON() is 0 there.

Hence, https://codereview.chromium.org/2014343002/ moved
isGraphOwner() out of ENABLE(ASSERT), but forgot to do the same
in the cpp file. This causes link errors. However, removing the macro
there too requires removing it in a few other places too.

To unbreak bots and devs, just replace the DCHECKs added in that CL with
ASSERTs for now.

BUG=615093,  613332 
TBR=rtoy

Review URL: https://codereview.chromium.org/2017923002 .

Cr-Commit-Position: refs/heads/master@{#396462}

[modify] https://crrev.com/c117666ede47a2ee7c7e403ef43b3718b9d7c716/third_party/WebKit/Source/modules/webaudio/AbstractAudioContext.h
[modify] https://crrev.com/c117666ede47a2ee7c7e403ef43b3718b9d7c716/third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.cpp
[modify] https://crrev.com/c117666ede47a2ee7c7e403ef43b3718b9d7c716/third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.h

ClusterFuzz has detected this issue as fixed in range 396253:396347.

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

Fuzzer: ochang_domfuzzer
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race WRITE 1
Crash Address: 0x7d4800009c98
Crash State:
  blink::PannerHandler::markPannerAsDirty
  blink::AudioListener::updateState
  blink::AbstractAudioContext::handlePreRenderTasks
  
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=396253:396347

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv976cs99KjHbi_nIVJ-ax2isbeCz1I9Z1pre5FRglZuzDFP6ZwlKnHoq08RaCIlilACynzpztEWbVzJOmeL-OR_Ub-JEWDII67AdnDtkqtNJhbyvSMq92qkmtPMvskeegChuRnxbUJqi9MVYrEJFzTWJqEsq5g


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.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot