mash: Check failure in TransportIdForWindow() during login |
||||||
Issue descriptionFlaky failure causing a few login-related browser tests to fail. Also seems to happen on real logins sometimes. [172276:172276:1103/132644.626594:FATAL:window_tree.cc(1170)] Check failed: iter != window_id_to_client_id_map_.end(). #0 0x7f6020a1583c base::debug::StackTrace::StackTrace() #1 0x7f6020a3c23c logging::LogMessage::~LogMessage() #2 0x000003df6161 ui::ws::WindowTree::TransportIdForWindow() #3 0x000003df93f6 ui::ws::WindowTree::DispatchInputEventImpl() #4 0x000003df9115 ui::ws::WindowTree::DispatchInputEvent() #5 0x000003decb33 ui::ws::WindowManagerState::DispatchInputEventToWindowImpl() #6 0x000003dede78 ui::ws::WindowManagerState::ProcessNextAvailableEvent() #7 0x000003deb6ee ui::ws::WindowManagerState::OnEventAck() #8 0x000001987f13 _ZN4base8internal7InvokerINS0_9BindStateIMN11google_apis5drive18BatchUploadRequestEFvPvNS3_17DriveApiErrorCodeEEJNS_7WeakPtrIS5_EEPNS3_17BatchableDelegateEEEEFvS7_EE3RunEPNS0_13BindStateBaseEOS7_ #9 0x0000019b67e2 _ZNO4base12OnceCallbackIFvN6device5mojom17UsbTransferStatusEEE3RunES3_ #10 0x000003dfe4d1 ui::ws::WindowTree::OnWindowInputEventAck() #11 0x000001d3cfb6 ui::mojom::WindowTreeStubDispatch::Accept() #12 0x7f601e3c646b mojo::InterfaceEndpointClient::HandleValidatedMessage() #13 0x7f601e3c5d66 mojo::FilterChain::Accept() #14 0x7f601e3c77d5 mojo::InterfaceEndpointClient::HandleIncomingMessage() #15 0x7f601e3d19d2 mojo::internal::MultiplexRouter::ProcessIncomingMessage() #16 0x7f601e3d0f04 mojo::internal::MultiplexRouter::Accept() #17 0x7f601e3c5d66 mojo::FilterChain::Accept() #18 0x7f601e3c0de5 mojo::Connector::ReadSingleMessage() #19 0x7f601e3c18d1 mojo::Connector::ReadAllAvailableMessages() #20 0x7f601e3c1779 mojo::Connector::OnHandleReadyInternal() #21 0x7f601e3c1f76 mojo::SimpleWatcher::DiscardReadyState() #22 0x7f601e389747 mojo::SimpleWatcher::OnHandleReady() #23 0x7f601e389c61 _ZN4base8internal7InvokerINS0_9BindStateIMN4mojo13SimpleWatcherEFvijRKNS3_18HandleSignalsStateEEJNS_7WeakPtrIS4_EEijS5_EEEFvvEE7RunImplIRKS9_RKNSt3__15tupleIJSB_ijS5_EEEJLm0ELm1ELm2ELm3EEEEvOT_OT0_NSI_16integer_sequenceImJXspT1_EEEE #24 0x7f6020a16125 base::debug::TaskAnnotator::RunTask() #25 0x7f6020a475c9 base::internal::IncomingTaskQueue::RunTask() #26 0x7f6020a4b188 base::MessageLoop::RunTask()
,
Nov 3 2017
Running this will usually generate a couple crashes: testing/xvfb.py out/Default/browser_tests --mash --test-launcher-retry-limit=0 --test-launcher-jobs=16 --gtest_filter="*Login*Test*"
,
Nov 3 2017
,
Nov 3 2017
This is happening because an event ends up targetting a window created in the renderer but is send to the browser (because the browser specified kEmbedFlagEmbedderInterceptsEvents). I think we need to make it so the browser sees all the created windows in this case, otherwise I have a hard time envisioning how the browser is going to handle dispatching events to the correct renderer.
,
Nov 9 2017
Is this stack the same issue? I'm seeing this in some mash browser_tests locally. [148978:148978:1109/154509.520344:FATAL:window_manager_state.cc(527)] Check failed: event_dispatcher_.mouse_cursor_source_window(). #0 0x7f1959d3bdfc base::debug::StackTrace::StackTrace() #1 0x7f1959d6285c logging::LogMessage::~LogMessage() #2 0x000003dfe898 ui::ws::WindowManagerState::DispatchInputEventToWindowImpl() #3 0x000003dffaf5 ui::ws::WindowManagerState::DispatchInputEventToWindow() #4 0x000003e1e6a2 ui::ws::EventDispatcher::DispatchToClient() #5 0x000003e1eb07 ui::ws::EventDispatcher::UpdateTargetForPointer() #6 0x000003e1dea4 ui::ws::EventDispatcher::ProcessPointerEventOnFoundTargetImpl() #7 0x000003e1d9c1 ui::ws::EventDispatcher::ProcessPointerEventOnFoundTarget() #8 0x000003e1ff0b ui::ws::EventTargeter::FindTargetForLocationNow() #9 0x000003e1fd7c ui::ws::EventTargeter::FindTargetForLocation() #10 0x000003e1d5f9 ui::ws::EventDispatcher::ProcessEvent() #11 0x000003dfe213 ui::ws::WindowManagerState::ProcessEventImpl() #12 0x000003dfdafc ui::ws::WindowManagerState::ProcessEvent() #13 0x000003e1b58d ui::ws::Display::OnEventFromSource() #14 0x7f1954c94ae8 ui::EventSource::SendEventToSink() #15 0x000003e235f2 ui::ws::PlatformDisplayDefault::DispatchEvent() #16 0x7f1954c96724 ui::DispatchEventFromNativeUiEvent() #17 0x7f194c7efc11 ui::X11WindowOzone::DispatchEvent() #18 0x7f19576e8476 ui::PlatformEventSource::DispatchEvent() #19 0x7f194c825ca4 ui::X11EventSourceLibevent::ProcessXEvent() #20 0x7f194c821530 ui::X11EventSource::ExtractCookieDataDispatchEvent() #21 0x7f194c82149d ui::X11EventSource::DispatchXEvents() #22 0x7f1959d73f63 base::MessagePumpLibevent::OnLibeventNotification() #23 0x7f1959e3a38d event_base_loop #24 0x7f1959d742c2 base::MessagePumpLibevent::Run() #25 0x7f1959d71149 base::MessageLoop::Run() #26 0x7f1959da5828 base::RunLoop::Run() #27 0x7f19568efcb3 content::UtilityMain() #28 0x7f19568fb581 content::ContentMainRunnerImpl::Run() #29 0x7f19544edf0b service_manager::Main() #30 0x7f19568f9f64 content::ContentMain() #31 0x000002927095 content::LaunchTests() #32 0x00000237e735 LaunchChromeTests() #33 0x00000237e186 RunMashBrowserTests() #34 0x00000237e037 main #35 0x7f194d9a8f45 __libc_start_main #36 0x000000781faa _start
,
Nov 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a7d8492b764e5e5c900d62e5c9b518ed4d8b2e52 commit a7d8492b764e5e5c900d62e5c9b518ed4d8b2e52 Author: James Cook <jamescook@chromium.org> Date: Fri Nov 10 00:12:36 2017 cros: Disable some flaky mash_browser_tests I left them commented out in the filter file because they do work, they just seem to trip flaky failures that are not particularly related to the code under test. Bug: 781391 , 783450 Test: browser_tests --mash Change-Id: I293c5e4ecb41b35a9effd9ced8d8b5773e7f49d9 Reviewed-on: https://chromium-review.googlesource.com/762336 Commit-Queue: James Cook <jamescook@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#515358} [modify] https://crrev.com/a7d8492b764e5e5c900d62e5c9b518ed4d8b2e52/testing/buildbot/filters/mash.browser_tests.filter [modify] https://crrev.com/a7d8492b764e5e5c900d62e5c9b518ed4d8b2e52/testing/buildbot/filters/mojo.fyi.mash.browser_tests.filter
,
Nov 10 2017
That is a separate issue. Please file a new one (and list which tests are tripping over it).
,
Nov 10 2017
Filed issue 783492 with list of tests (I was seeing it in extensions browser tests).
,
Nov 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/dd1f47bfc9153f65b1c9438b539844f18c3587bb commit dd1f47bfc9153f65b1c9438b539844f18c3587bb Author: Scott Violet <sky@chromium.org> Date: Mon Nov 13 21:19:10 2017 chromeos: expose child windows to client at embed point When a client embeds another client it can choose to intercept events by specifying kEmbedFlagEmbedderInterceptsEvents. When this happens events targetted at windows created by the embedded client go to the embedder. When this happens the embedder needs to know about the windows created by the embedded client, otherwise it has no way to know the real target. This patch makes it so that if kEmbedFlagEmbedderInterceptsEvents was specified (and the client was not created by way of Embed()) then the embedder client sees all windows created by any embedded client. The embedder can still not operate on the windows, but it sees the windows. In terms of chrome this makes it so that browser sees the windows created by renderers. Renderers can not see any windows created by other renderers (even ones embedded in renderers). The long term goal is to get rid of kEmbedFlagEmbedderInterceptsEvents, at which point this will be removed. BUG= 781391 TEST=covered by test Change-Id: I110d3205cd3b9c3bfa0e78760dd58b517fa43856 Reviewed-on: https://chromium-review.googlesource.com/760797 Commit-Queue: Scott Violet <sky@chromium.org> Reviewed-by: Elliot Glaysher <erg@chromium.org> Reviewed-by: Tom Sepez <tsepez@chromium.org> Cr-Commit-Position: refs/heads/master@{#516050} [modify] https://crrev.com/dd1f47bfc9153f65b1c9438b539844f18c3587bb/services/ui/ws/access_policy_delegate.h [modify] https://crrev.com/dd1f47bfc9153f65b1c9438b539844f18c3587bb/services/ui/ws/default_access_policy.cc [modify] https://crrev.com/dd1f47bfc9153f65b1c9438b539844f18c3587bb/services/ui/ws/test_utils.cc [modify] https://crrev.com/dd1f47bfc9153f65b1c9438b539844f18c3587bb/services/ui/ws/test_utils.h [modify] https://crrev.com/dd1f47bfc9153f65b1c9438b539844f18c3587bb/services/ui/ws/window_tree.cc [modify] https://crrev.com/dd1f47bfc9153f65b1c9438b539844f18c3587bb/services/ui/ws/window_tree.h [modify] https://crrev.com/dd1f47bfc9153f65b1c9438b539844f18c3587bb/services/ui/ws/window_tree_unittest.cc
,
Nov 13 2017
,
Nov 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/df938c4d96fb74f1be5d6840c1d2871967a51038 commit df938c4d96fb74f1be5d6840c1d2871967a51038 Author: James Cook <jamescook@chromium.org> Date: Thu Nov 16 20:02:55 2017 chromeos: Enable WebviewLoginTest in mash_browser_tests The underlying bug was fixed and it's stable on the FYI bot. Bug: 781391 Change-Id: I291f5b1ec376c27801c03c6217de65b9b98fd664 Reviewed-on: https://chromium-review.googlesource.com/772873 Commit-Queue: James Cook <jamescook@chromium.org> Reviewed-by: Michael Wasserman <msw@chromium.org> Cr-Commit-Position: refs/heads/master@{#517160} [modify] https://crrev.com/df938c4d96fb74f1be5d6840c1d2871967a51038/testing/buildbot/filters/mash.browser_tests.filter
,
Jan 22 2018
,
Jan 23 2018
,
Feb 26 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by sadrul@chromium.org
, Nov 3 2017