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

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

Looks like a AudioWorklet problem.

It seems like another rapid-refresh crasher. My guess is the destination node is already gone when the worklet signals the context.

FWIW, I cannot reproduce this locally with the CF reproducing tool.

ClusterFuzz has detected this issue as fixed in range 554638:554639.

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

Fuzzer: inferno_twister
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000058
Crash State:
  blink::AudioNode::Handler
  blink::AudioDestinationNode::GetAudioDestinationHandler
  blink::BaseAudioContext::NotifyWorkletIsReady
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=547367:547368
Fixed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=554638:554639

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

Additional requirements: Requires HTTP

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 6245700061626368 is verified as fixed, so closing issue as verified.

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

Since I can't reproduce locally even after several runs, so I would leave this as "fixed" for now. Will tackle it if it ever comes up again.

Since this keeps coming back in CF, I will make this as a primary tracking bug for this issue.

 Issue 840164  has been merged into this issue.

 Issue 842518  has been merged into this issue.

I can only speculate since I cannot reproduce this locally.

- BaseAudioContext is created.
- audioWorklet.addModule(url) is called.
- BaseAudioContext starts shutting down.
- audioWorklet finishes the loading and notify the context.
- When the notification arrives, the context's destination is already destroyed.
- Crashes with NULL-deference.

Had an offline discussion with rtoy@ and came with a possible scenario:

1. BaseAudioContext is created.
2. audioWorklet.addModule(url) is called.
3. The user code has not called context.startRendering() and the context goes out of scope.
4. Because 1) the context is out of scope and 2) its |hasPendingActivity()| returns false, the context is getting GCed.
   :|hasPendingActivity()| returns false when context.startRendering() is not called.
5. The callback from the WorkletGlobalScope after module loading arrives, but it causes a crash because the context is gone.

To fix this, the BaseAudioContext should be signaled when "addModule" is called, and wait until module loading is finished. During this time frame, the context's |hasPendingActivity| must return true.

WDYT - nhiroki@, haraken@?

Sounds reasonable to me.

SGTM

 Issue 844871  has been merged into this issue.

The speculative fix has landed: https://chromium-review.googlesource.com/c/chromium/src/+/1062795

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

 Issue 846017  has been merged into this issue.

ClusterFuzz has detected this issue as fixed in range 557106:557107.

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

Fuzzer: inferno_twister
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000058
Crash State:
  blink::AudioNode::Handler
  blink::AudioDestinationNode::GetAudioDestinationHandler
  blink::BaseAudioContext::NotifyWorkletIsReady
  
Sanitizer: memory (MSAN)

Fixed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=557106:557107

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

Additional requirements: Requires HTTP

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 6090501061869568 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.

Seems weird.

The test case 6245700061626368 (#20) and 6090501061869568 (#19) looks exactly identical  in terms of the stack trace, but CF says #19 is still reproducible. I call CF is being flaky, so I would give it some times.

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

commit 02bbc0c42eb8ee798aa633942563b9e3478716ef
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Tue Jun 05 07:07:07 2018

worklet: Adding missing braces to WorkletPendingTasks::DecrementCounter()

Commit 629360d2d ("Check WorkletPendingTasks when BaseAudioContext is going
away") added a call to Worket::FinishPendingTasks() while not adding brances
to the enclosing if clause. GCC warns about this with -Wmisleading-indent,
and the behavior does look wrong here, as the spec says the corresponding
promise should only be resolved when counter is 0.

Bug:  836942 
Change-Id: Ib4a197912974af10c8272efb7bb95106a3d0e6f0
Reviewed-on: https://chromium-review.googlesource.com/1085064
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#564388}
[modify] https://crrev.com/02bbc0c42eb8ee798aa633942563b9e3478716ef/third_party/blink/renderer/core/workers/worklet_pending_tasks.cc

nhiroki@, will you take care of the M68 merge process or should I do it myself?

raphael.kubo.da.costa@, thank you for the fix! I'll merge it.

The NextAction date has arrived: 2018-06-07

Let me merge the small patch on c#23 to M68. The patch fixes a bug accidentally added in M68. Without the patch, Worklets may go into an unexpected state and be flaky.

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

Approving merge to 68. Branch:3440

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

commit e21b3320623a165a3f644faf2ecf45f39da3ae62
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Fri Jun 08 02:09:33 2018

[Merge to M68] worklet: Adding missing braces to WorkletPendingTasks::DecrementCounter()

This CL was originally created by Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>

Commit 629360d2d ("Check WorkletPendingTasks when BaseAudioContext is going
away") added a call to Worket::FinishPendingTasks() while not adding brances
to the enclosing if clause. GCC warns about this with -Wmisleading-indent,
and the behavior does look wrong here, as the spec says the corresponding
promise should only be resolved when counter is 0.

Bug:  836942 
Change-Id: Ib4a197912974af10c8272efb7bb95106a3d0e6f0
Reviewed-on: https://chromium-review.googlesource.com/1085064
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Original-Commit-Position: refs/heads/master@{#564388}(cherry picked from commit 02bbc0c42eb8ee798aa633942563b9e3478716ef)
Reviewed-on: https://chromium-review.googlesource.com/1092170
Cr-Commit-Position: refs/branch-heads/3440@{#254}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/e21b3320623a165a3f644faf2ecf45f39da3ae62/third_party/blink/renderer/core/workers/worklet_pending_tasks.cc

Merge is done. Let me return the ownership to the original owner.

ClusterFuzz has detected this issue as fixed in range 558953:558958.

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

Fuzzer: inferno_twister
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000058
Crash State:
  blink::AudioNode::Handler
  blink::AudioDestinationNode::GetAudioDestinationHandler
  blink::BaseAudioContext::NotifyWorkletIsReady
  
Sanitizer: memory (MSAN)

Fixed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=558953:558958

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

Additional requirements: Requires HTTP

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.

Thanks nhiroki@! Once again CF verified the fix.