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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/c5a356a9c5634c5f1e48e86411b8a6ec4ffaacb1 (Load worklet modules off-main-thread).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

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

Moving worklet module loading off-main-thread is unlikely to have caused a crash after the module has been evaluated, so I'm skeptical my CL is responsible.

Re-assigning to a webaudio owner, feel free to bounce back to me if you disagree with my triage.

CF already marked this as unreproducible. I'll monitor the progress.

https://chromium.googlesource.com/chromium/src/+/796ffd72c03cf6092767c995397e3820212ab0c9/third_party/blink/renderer/modules/webaudio/base_audio_context.cc#898

We have to consider that context() might be gone already. The solution would be:

1. Don't come back to the main thread if the context doesn't exist.
2. The AudioContext holds the pending cross-thread call, and use it for HasPendingActivity().

 Issue 856167  has been merged into this issue.

I investigated a bit more:

The option 2 in #6 seems to be already covered by HasPendingActivity() check in BaseAudioContext. We're already checking if worklet()->HasPendingTasks() and the context cannot go away if there is a module loading task in the queue.

I followed the code path of BaseAudioContext::NotifyWorkletIsReady() and Worklet::HadPendingTasks() functions. The former must happen before the latter - which means executing NotifyWorkletIsReady() should be okay if there is any unfinished worklet tasks.

So I think it might be worth doing a temporary fix that prevents NotifyWorkletIsReady() from accessing destination() by early-quitting the function if the context is "cleared".

cc nhiroki@: Did I explain Worklet::HasPendingTasks() behavior correctly?

FWIW, I cannot reproduce this locally even with the clusterfuzz tool.

estark@ I don't think this has security impact, but should we apply the restricted-view label?

Cannot reproduce this locally using clusterfuzz tool.  And clusterfuzz says it's flaky now too.

ClusterFuzz testcase 4701335933681664 is flaky and no longer crashes, so closing issue.

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