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

Issue 622134 link

Starred by 3 users

Issue metadata

Status: Verified
Owner:
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

[FATAL:top_controls_manager.cc(190)] Check failed: direction != HIDING_CONTROLS || TopControlsShownRatio() > 0.f

Project Member Reported by w...@chromium.org, Jun 22 2016

Issue description

I hit this while entering/exiting fullscreen video a bunch of times. Happened on storage.googelapis.com/watk/v but it probably doesn't matter. Nexus 5. Current debug build of M53.

loyso@, do you know who would be best to look at this?




signal 6 (SIGABRT), code -6 in tid 26625 (Compositor)
pid: 26572, tid: 26625, name: Compositor  >>> org.chromium.chrome:sandboxed_process1 <<<
[FATAL:top_controls_manager.cc(190)] Check failed: direction != HIDING_CONTROLS || TopControlsShownRatio() > 0.f. 

Stack Trace:
  00041f50  tgkill+12 /system/lib/libc.so
  0003fb5d  pthread_kill+32  /system/lib/libc.so
  0001c30f  raise+10  /system/lib/libc.so
  000194c1  __libc_android_abort+34  /system/lib/libc.so
  000173ac  abort+4  /system/lib/libc.so
  000aee69  DebugBreak  /s/c/src/base/debug/debugger_posix.cc:219
  000aee7f  base::debug::BreakDebugger()  /s/c/src/base/debug/debugger_posix.cc:249
  000e3f93  logging::LogMessage::~LogMessage()    /s/c/src/base/logging.cc:748
  000ee453  cc::TopControlsManager::SetupAnimation(cc::TopControlsManager::AnimationDirection)    /s/c/src/cc/input/top_controls_manager.cc:190
  000ede67  cc::TopControlsManager::UpdateTopControlsState(cc::TopControlsState, cc::TopControlsState, bool) /s/c/src/cc/input/top_controls_manager.cc:91
  002ceca9  cc::ProxyImpl::UpdateTopControlsStateOnImpl(cc::TopControlsState, cc::TopControlsState, bool) /s/c/src/cc/trees/proxy_impl.cc:141
  002f2983  void base::internal::RunnableAdapter<void (cc::ProxyImpl::*)(cc::TopControlsState, cc::TopControlsState, bool)>::Run<base::WeakPtr<cc::ProxyImpl> const&, cc::TopControlsState const&, cc::TopControlsState const&, bool const&>(base::WeakPtr<cc::ProxyImpl> const&, cc::TopControlsState const&, cc::TopControlsState const&, bool const&)  /s/c/src/base/bind_internal.h:187
  002f268f  void base::internal::InvokeHelper<true, void>::MakeItSo<base::internal::RunnableAdapter<void (cc::ProxyImpl::*)(cc::TopControlsState, cc::TopControlsState, bool)>&, base::WeakPtr<cc::ProxyImpl> const&, cc::TopControlsState const&, cc::TopControlsState const&, bool const&>(base::internal::RunnableAdapter<void (cc::ProxyImpl::*)(cc::TopControlsState, cc::TopControlsState, bool)>&, base::WeakPtr<cc::ProxyImpl> const&, cc::TopControlsState const&, cc::TopControlsState const&, bool const&)  /s/c/src/base/bind_internal.h:325
  002f21ad  base::internal::Invoker<base::IndexSequence<0u, 1u, 2u, 3u>, base::internal::BindState<base::internal::RunnableAdapter<void (cc::ProxyImpl::*)(cc::TopControlsState, cc::TopControlsState, bool)>, void (cc::ProxyImpl*, cc::TopControlsState, cc::TopControlsState, bool), base::WeakPtr<cc::ProxyImpl>&, cc::TopControlsState&, cc::TopControlsState&, bool&>, true, void ()>::Run(base::internal::BindStateBase*) /s/c/src/base/bind_internal.h:367
  0009d301  base::Callback<void (), (base::internal::CopyMode)1>::Run() const /s/c/src/base/callback.h:397
  000afbe5  base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask const&) /s/c/src/base/debug/task_annotator.cc:51

 

Comment 1 by suzyh@chromium.org, Jun 22 2016

Cc: loyso@chromium.org
Owner: vollick@chromium.org
loyso is on leave at the moment. vollick, can you please redirect?
Cc: samu...@chromium.org vollick@chromium.org
Owner: bokan@chromium.org
+ bokan@,

We are seeing a lot of flakiness on our ChromeDriver Android bot due to this same browser crash.

"FATAL:top_controls_manager.cc(191)] Check failed: direction != SHOWING_CONTROLS || TopControlsShownRatio() < 1.f."

Crash occurs during execution of 'testGoBackAndGoForward' of run_py_tests.py.
We performed bisect and found that the culprit CL seems to be crrev.com/399036


Repro steps for the ChromeDriver test:

1. Build and install chrome_public_apk
2. Build chromedriver or download it from http://chromedriver.storage.googleapis.com/index.html?path=2.22/
3. Run the following command in a chromium (android) checkout:

chrome/test/chromedriver/test/run_py_tests.py --chromedriver=$HOME/Downloads/chromedriver --android-package=chromium --filter=*.testGoBackAndGoForward

The test itself is quite simple - it just sends a few commands (Page.navigateToHistoryEntry) to the DevTools remote debugger to go back and forward in the history - and causes a similar assertion failure:

"FATAL:top_controls_manager.cc(191)] Check failed: direction != SHOWING_CONTROLS || TopControlsShownRatio() < 1.f."

Comment 4 by bokan@chromium.org, Jun 22 2016

It seems like we're asking the top controls to start showing but they're already fully shown. Interestingly, all paths into SetupAnimation seem to have already checked for this so it's not immediately clear to me where this is going wrong. I'll dig into this in the next day or two.

Comment 5 by bokan@chromium.org, Jun 22 2016

I was unable to reproduce this locally but I'm fairly certain I know where the issue lies. Explanation and fix at https://codereview.chromium.org/2090223002
Project Member

Comment 6 by bugdroid1@chromium.org, Jun 23 2016

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

commit 0223f2f72d17879c727bb6a1915e43931b3e8771
Author: bokan <bokan@chromium.org>
Date: Thu Jun 23 12:35:01 2016

Clamp compositor's top controls shown ratio on commit from main thread.

The shown_ratio should always be in the range [0,1] and this is enforced when
top controls are scrolled. However, we did not enforce this constraint when a
new value is committed from the main thread. This means that if there's an
existing delta on the compositor's active tree value and the main thread commits
a new base value we can see values of the ratio outside this range and this
causes us to violate some assumptions in DCHECKs.

BUG= 622134 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2090223002
Cr-Commit-Position: refs/heads/master@{#401588}

[modify] https://crrev.com/0223f2f72d17879c727bb6a1915e43931b3e8771/cc/trees/layer_tree_host_impl_unittest.cc
[modify] https://crrev.com/0223f2f72d17879c727bb6a1915e43931b3e8771/cc/trees/layer_tree_impl.cc
[modify] https://crrev.com/0223f2f72d17879c727bb6a1915e43931b3e8771/cc/trees/layer_tree_impl.h

Comment 7 by bokan@chromium.org, Jun 23 2016

The speculative fix is in. Could you guys give it a try on ToT (since I couldn't repro) and see if it helps?
Thanks for the fix!

Executed the test for 300 tries locally, issue is no longer reproducible.

Comment 9 by bokan@chromium.org, Jun 23 2016

Status: Fixed (was: Available)
sgtm, feel free to reopen if you still see it once the bots cycle the change.
Status: Verified (was: Fixed)
Chromedriver android bot is green again!
https://build.chromium.org/p/chromium.fyi/builders/Android%20ChromeDriver%20Tests%20%28dbg%29
Status: Fixed (was: Verified)
Sorry, changing the status back to Fixed for watk@ to verify separately, in case he was running into something different.

Comment 12 by w...@chromium.org, Jun 24 2016

Status: Verified (was: Fixed)
Wasn't super common, so I'll assume it's the same issue unless I run into it again :)

Sign in to add a comment