Predator and CL could not provide any possible suspects.
Using Code Search for the file, "DynamicsCompressorNode.cpp" assigning to concern owner.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/df2695285dbd49fc66d940ea08c71e09e9cc5583

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

Not sure why the listed CL would cause this test to regress, but I can reproduce this locally just by running a tsan build.

ClusterFuzz has detected this issue as fixed in range 495172:495180.

Detailed report: https://clusterfuzz.com/testcase?key=4826531200499712

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race WRITE 4
Crash Address: 0x7b2c00005cb8
Crash State:
  blink::DynamicsCompressorHandler::Process
  blink::AudioHandler::ProcessIfNecessary
  blink::AudioNodeOutput::Pull
  
Sanitizer: thread (TSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=478278:478292
Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=495172:495180

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4826531200499712

See https://github.com/google/clusterfuzz-tools 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 4826531200499712 is verified as fixed, so closing issue as verified.

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

 Issue 765580  has been merged into this issue.

Reopening.   issue 765580  shows that this hasn't been fixed.

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.

We will hopefully fix this when tail processing lands (soon?).  The offending code in ClearInternalState will be removed with tail processing.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

I think we have a data race on |redunction_| in DynamicsCompressorHandler class. Does the tail processing solve this data race somehow?

Yes, because we removed the function ClearInternalStateWhenDisabled() which sets reduction_ (from both the main thread and audio thread, I think).

See https://chromium-review.googlesource.com/c/chromium/src/+/661165/21/third_party/WebKit/Source/modules/webaudio/DynamicsCompressorNode.cpp

Hmm. I don't think the change solve the data race. The getter from the main thread still can access |reduction_| while the value is being updated by process() call.

Not ideal, but we can use a mutex for updating/accessing this value:
https://chromium-review.googlesource.com/c/chromium/src/+/927713

Otherwise we might have to come up with a more complex design.

Yes it fixes the worst of it because the main thread could set the value to 0 and the audio thread right after change it to something else, breaking the purpose of that routine.

It's true that the main thread could read the value just before the audio thread up dates its, but that just means the main thread has a slightly old value.

The value not being updated correctly is a different problem. This bug entry is about the data race in the code, I think the CL in #15 fixes that.

We should try to address the incorrect value problem separately.

As we discussed offline:

1. Leave this as it is until the tail processing lands.
2. Use the atomic access for |reduction_| after the tail processing CL.

FWIW, the clusterfuzz could not reproduce this locally on Rodete.

ClusterFuzz has detected this issue as fixed in range 541309:541311.

Detailed report: https://clusterfuzz.com/testcase?key=4826531200499712

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race WRITE 4
Crash Address: 0x7b2c00005cb8
Crash State:
  blink::DynamicsCompressorHandler::Process
  blink::AudioHandler::ProcessIfNecessary
  blink::AudioNodeOutput::Pull
  
Sanitizer: thread (TSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=478278:478292
Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=541309:541311

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4826531200499712

See https://github.com/google/clusterfuzz-tools for more information.

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

I think clusterfuzz is wrong.  The fixed region has nothing to do with webaudio and we haven't (explicitly) fixed this in any way yet.

ClusterFuzz has detected this issue as fixed in range 543877:543884.

Detailed report: https://clusterfuzz.com/testcase?key=4826531200499712

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race WRITE 4
Crash Address: 0x7b2c00005cb8
Crash State:
  blink::DynamicsCompressorHandler::Process
  blink::AudioHandler::ProcessIfNecessary
  blink::AudioNodeOutput::Pull
  
Sanitizer: thread (TSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=478278:478292
Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=543877:543884

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4826531200499712

See https://github.com/google/clusterfuzz-tools for more information.

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

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

commit bc40a7f9dedf9dc230b3c245677d0740564b8e77
Author: Hongchan Choi <hongchan@chromium.org>
Date: Wed Apr 18 02:09:40 2018

Use NoBarrierStore/Load to suppress TSAN warning.

Currently |reduction_| in DynamicsCompressorHandler is accessed by
two different threads without any protection. Adding
NoBarrierStore/Load will suppress the warning, and also
indicates that we have a benign data race in |reduction_|.

See also: https://codereview.chromium.org/1461743002/

Bug:  755393 
Change-Id: I3946772b55fdd6b6e7c806058306d0f81a855c69
Reviewed-on: https://chromium-review.googlesource.com/927713
Commit-Queue: Hongchan Choi <hongchan@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551555}
[modify] https://crrev.com/bc40a7f9dedf9dc230b3c245677d0740564b8e77/third_party/blink/renderer/modules/webaudio/dynamics_compressor_node.cc
[modify] https://crrev.com/bc40a7f9dedf9dc230b3c245677d0740564b8e77/third_party/blink/renderer/modules/webaudio/dynamics_compressor_node.h

ClusterFuzz testcase 4826531200499712 appears to be flaky, updating reproducibility label.

I think this is really fixed.  The tail processing CL removed the cause of the original test case because the main thread was writing a value that the audio thread could also be reading and writing.

The second CL in c#22 should have fixed the case where main thread could be reading a float value when the audio thread was writing it.

ClusterFuzz has detected this issue as fixed in range 543877:543884.

Detailed report: https://clusterfuzz.com/testcase?key=4826531200499712

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race WRITE 4
Crash Address: 0x7b2c00005cb8
Crash State:
  blink::DynamicsCompressorHandler::Process
  blink::AudioHandler::ProcessIfNecessary
  blink::AudioNodeOutput::Pull
  
Sanitizer: thread (TSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=478278:478292
Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=543877:543884

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4826531200499712

See https://github.com/google/clusterfuzz-tools for more information.

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

jbroman@

I thought you'd want to know. The fixed range seems incorrect, but I believe this is fixed by a series of your CLs. Thanks again!