New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 835713 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Check failed: context_state_ == kSuspended (1 vs. 0)

Project Member Reported by alancutter@chromium.org, Apr 23 2018

Issue description

Chrome Version: 68.0.3404.0 
OS: chromeOS

What steps will reproduce the problem?
(1) Build Chrome with assertions enabled.
(2) Visit: https://airhorner.com/
(3) Press the button.

What is the expected result?

No crash.

What happens instead?

[1:1:0423/154244.758313:FATAL:base_audio_context.cc(638)] Check failed: context_state_ == kSuspended (1 vs. 0)       
#0 0x7f259a20155c base::debug::StackTrace::StackTrace()
#1 0x7f259a14903b logging::LogMessage::~LogMessage()                                                                 
#2 0x7f258f15e93e blink::BaseAudioContext::SetContextState()
#3 0x7f258f15fa2d blink::BaseAudioContext::PerformCleanupOnMainThread()                                              
#4 0x7f258f8d0cbb blink::(anonymous namespace)::RunCrossThreadClosure()
#5 0x7f258f8d1555 _ZN4base8internal7InvokerINS0_9BindStateIPFvN3WTF19CrossThreadFunctionIFvvEEEEJS6_EEES5_E7RunOnceEP
NS0_13BindStateBaseE
#6 0x7f259a12b4a5 base::debug::TaskAnnotator::RunTask()
#7 0x7f258f9848b1 blink::scheduler::internal::ThreadControllerImpl::DoWork()
#8 0x7f258f98661b _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler8internal20ThreadControllerImplEFvNS5_19
SequencedTaskSource8WorkTypeEEJNS_7WeakPtrIS6_EES8_EEEFvvEE3RunEPNS0_13BindStateBaseE
#9 0x7f259a12b4a5 base::debug::TaskAnnotator::RunTask()
#10 0x7f259a155429 base::internal::IncomingTaskQueue::RunTask()
#11 0x7f259a15891b base::MessageLoop::RunTask()
#12 0x7f259a158caa base::MessageLoop::DeferOrRunPendingTask()
#13 0x7f259a158f0c base::MessageLoop::DoWork()
#14 0x7f259a15b226 base::MessagePumpDefault::Run()
#15 0x7f259a158304 base::MessageLoop::Run()
#16 0x7f259a18aab9 base::RunLoop::Run()
#17 0x7f2597b792cd content::RendererMain()
#18 0x7f2597d0f52e content::RunZygote()
#19 0x7f2597d10ead content::ContentMainRunnerImpl::Run()
#20 0x7f259a672292 service_manager::Main()
#21 0x7f2597d0eb24 content::ContentMain()
#22 0x55e6fcd03723 ChromeMain       
#23 0x7f258cad52b1 __libc_start_main
#24 0x55e6fcd0359a _start           

 
Labels: OS-Linux

Comment 2 by rtoy@chromium.org, Apr 23 2018

Unable to reproduce using ToT Chromium, release build, with dcheck_always_on = true.  Debug build fails to reproduce as well.

Is there something special I need to do?  I pressed the horn many times and still no dcheck error.

Comment 3 by rtoy@chromium.org, Apr 23 2018

Cc: cwilso@chromium.org
Owner: mlamouri@chromium.org
Status: Assigned (was: Untriaged)
Oh, I normally run with autoplay policy turned off.  A release build with dchecks enabled or a debug build does crash with the DCHECK.

But both PLAY the audio, even though there's a message (in a debug build) that the audio context was not started from a user gesture.

So there are two issues here:  the audio plays, and the dcheck fails.

+mlamouri who implemented the autoplay policy for webaudio.


Cc: paulkinlan@chromium.org

Comment 5 by rtoy@chromium.org, Apr 24 2018

Cc: mlamouri@chromium.org
Owner: rtoy@chromium.org
Status: Started (was: Assigned)
Project Member

Comment 6 by bugdroid1@chromium.org, Apr 25 2018

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

commit eb308ab0f64615b796dbc716cbbea27ca3e843b9
Author: Raymond Toy <rtoy@chromium.org>
Date: Wed Apr 25 16:11:45 2018

Nothing to do if state isn't changing

In the test case in 835713, the page calls context.resume()
twice. Once on load and once on a user gesture.  The first call to
resume has a promise pending that gets resolved when the second
promise is resolved when the context is finally allowed to start.

As part of the resolution of the promise, the context state is set to
"running", which happens in the first promise.  The second promise
does this again.  But SetContextState checks for valid state
transitions, and running->running isn't one of them.  However, if the
state isn't changing, there's nothing that needs to be done, so
SetContextStae can return early.

Bug:  835713 
Test: repro case no longer DCHECKs
Change-Id: Iccfc88ce1caedc3cdf7cdfcf3e8ed4a84d4010e4
Reviewed-on: https://chromium-review.googlesource.com/1026082
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553591}
[modify] https://crrev.com/eb308ab0f64615b796dbc716cbbea27ca3e843b9/third_party/blink/renderer/modules/webaudio/base_audio_context.cc

Comment 7 by rtoy@chromium.org, Apr 27 2018

Status: Fixed (was: Started)

Sign in to add a comment