[FATAL:top_controls_manager.cc(190)] Check failed: direction != HIDING_CONTROLS || TopControlsShownRatio() > 0.f |
||||||
Issue descriptionI 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
,
Jun 22 2016
+ 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
,
Jun 22 2016
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."
,
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.
,
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
,
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
,
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?
,
Jun 23 2016
Thanks for the fix! Executed the test for 300 tries locally, issue is no longer reproducible.
,
Jun 23 2016
sgtm, feel free to reopen if you still see it once the bots cycle the change.
,
Jun 24 2016
Chromedriver android bot is green again! https://build.chromium.org/p/chromium.fyi/builders/Android%20ChromeDriver%20Tests%20%28dbg%29
,
Jun 24 2016
Sorry, changing the status back to Fixed for watk@ to verify separately, in case he was running into something different.
,
Jun 24 2016
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 |
||||||
Comment 1 by suzyh@chromium.org
, Jun 22 2016Owner: vollick@chromium.org