Possible suspect 
https://chromium.googlesource.com/chromium/src/+/a279c223c4de83378fb4aafe8b9ad0d309490867

hongchan@, could you please take a look and help us correct owner if it is not related your change.

Thank you

The following is the repro case.

1. Each concatenation increases the size of global array 512 * 4 bytes, which happens every 7ms.
2. So eventually this will crash with OOM, or 'audioprocess' callback just takes too long to run because of the size of the array.

---
<script>
 var actualBufferArrayC0 = new Float32Array();
 function concatTypedArray(arr1, arr2) {
   var result = new Float32Array(arr1.length + arr2.length);
   result.set(arr2);
   return result;
 }
 context = new AudioContext();
 processor = context.createScriptProcessor();
 processor.connect(context.destination);
 processor.addEventListener('audioprocess',
function (e) {
  actualBufferArrayC0 = concatTypedArray(actualBufferArrayC0, e.inputBuffer.getChannelData(0));
});
 </script>
---

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

To fix comment #3,

This is not an OOM issue. The array size keeps increasing as it goes, and the concat time will be longer up to a point where it goes above the next render quantum. When the next render quantum begins, |e.inputBuffer| will be accessed by the audio thread but it is still being accessed by the main thread via |result.set(arr2)|.

Then a data race happens.

However, this node is deprecated by the spec so we do not have plan to fix this. Please open the issue again if it blocks anything.

ClusterFuzz has detected this issue as fixed in range 464623:464642.

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

Fuzzer: attekett_dom_fuzzer
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race READ 8
Crash Address: 0x7d9000002000
Crash State:
  v8::internal::Runtime_TypedArraySetFastCases
  v8::internal::Execution::Call
  v8::Function::Call
  
Sanitizer: thread (TSAN)

Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=464623:464642

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


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.

 Issue 848985  has been merged into this issue.

Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

 Issue 855944  has been merged into this issue.

This is WontFix with the reasoning that the code is deprecated, but that comment is 15 months old by now. When do you expect this code to go away?

Re #10:

Yes, the feature is deprecated from the spec, but there is no clear deadline for the deprecation yet.

We (WebAudio team) think any reasonable solution for this issue will ruin many use cases of this feature out there. Its design is fundamentally flawed (racy by design) and that is the main reason of deprecation.

If Chromium has a guideline for such problem, we can use that to justify the actual code removal - but removing ScriptProcessorNode from Web Audio API will create a panic WebAudio developer community. We would like to navigate the plan carefully.

 Issue 865450  has been merged into this issue.