Dragging a window to the side in mash results in a validation error. |
|||||||||||||||
Issue descriptionWhat steps will reproduce the problem? (1) ./out/Debug/chrome --mash (2) Drag the first chrome window to the side to trigger the left or right window dock animation. (3) Crash! [18708:18708:0708/132446:177197400164:FATAL:render_pass_struct_traits.cc(15)] Check failed: input->quad_list.size() > 0u (0 vs. 0) #0 0x7ffaac14809e base::debug::StackTrace::StackTrace() #1 0x7ffaac1a3a0c logging::LogMessage::~LogMessage() #2 0x7ffa9dece194 mojo::StructTraits<>::SetUpContext() #3 0x7ffa9de4ffec mojo::internal::CustomContextHelper<>::SetUp<>() #4 0x7ffa9de4fe70 mojo::internal::Serializer<>::PrepareToSerialize() #5 0x7ffa9de4fd32 unsigned long mojo::internal::PrepareToSerialize<mojo::StructPtr<cc::mojom::RenderPass>, std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> > const&, mojo::internal::SerializationContext*&>(std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> > const&, mojo::internal::SerializationContext*&) #6 0x7ffa9de4fcb8 mojo::internal::ArraySerializer<>::GetSerializedSize() #7 0x7ffa9de4fc3d mojo::internal::Serializer<>::PrepareToSerialize() #8 0x7ffa9de4cce2 unsigned long mojo::internal::PrepareToSerialize<mojo::Array<mojo::StructPtr<cc::mojom::RenderPass> >, std::__debug::vector<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >, std::allocator<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> > > > const&, mojo::internal::SerializationContext*&>(std::__debug::vector<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >, std::allocator<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> > > > const&, mojo::internal::SerializationContext*&) #9 0x7ffa9de4cbab mojo::internal::Serializer<>::PrepareToSerialize() #10 0x7ffa9de4bf02 unsigned long mojo::internal::PrepareToSerialize<mojo::StructPtr<cc::mojom::CompositorFrame>, cc::CompositorFrame&, mojo::internal::SerializationContext*>(cc::CompositorFrame&, mojo::internal::SerializationContext*&&) #11 0x7ffa9de497e7 ui::mojom::SurfaceProxy::SubmitCompositorFrame() #12 0x7ffa9dd69d04 ui::WindowSurface::SubmitCompositorFrame() #13 0x7ffa9dd4c6de ui::OutputSurface::SwapBuffers() #14 0x7ffaa3bbec12 cc::DelegatingRenderer::SwapBuffers() #15 0x7ffaa3da1695 cc::LayerTreeHostImpl::SwapBuffers() #16 0x7ffaa3e47c49 cc::SingleThreadProxy::DoComposite() #17 0x7ffaa3e48aa9 cc::SingleThreadProxy::ScheduledActionDrawAndSwapIfPossible() #18 0x7ffaa3cdf687 cc::Scheduler::DrawAndSwapIfPossible() #19 0x7ffaa3cdaf7c cc::Scheduler::ProcessScheduledActions() #20 0x7ffaa3cdaae0 cc::Scheduler::OnBeginImplFrameDeadline() #21 0x7ffaa3b42822 void base::internal::FunctorTraits<void (cc::ScrollbarAnimationController::*)(), void>::Invoke<base::WeakPtr<cc::ScrollbarAnimationController>>(void (cc::ScrollbarAnimationController::*)(), base::WeakPtr<cc::ScrollbarAnimationController>&&) #22 0x7ffaa3ce2b99 void base::internal::InvokeHelper<true, void>::MakeItSo<void (cc::Scheduler::* const&)(), base::WeakPtr<cc::Scheduler>>(void (cc::Scheduler::* const&)(), base::WeakPtr<cc::Scheduler>) #23 0x7ffaa3ce2b1f void base::internal::Invoker<base::internal::BindState<void (cc::Scheduler::*)(), base::WeakPtr<cc::Scheduler> >, void ()>::RunImpl<void (cc::Scheduler::* const&)(), std::tuple<base::WeakPtr<cc::Scheduler> > const&, 0ul>(void (cc::Scheduler::* const&)(), std::tuple<base::WeakPtr<cc::Scheduler> > const&, base::IndexSequence<0ul>) #24 0x7ffaa3ce29bc base::internal::Invoker<base::internal::BindState<void (cc::Scheduler::*)(), base::WeakPtr<cc::Scheduler> >, void ()>::Run(base::internal::BindStateBase*) #25 0x7ffaa3b4289e base::Callback<>::Run() #26 0x7ffaa3b42429 base::CancelableCallback<>::Forward() #27 0x7ffaa3b42822 void base::internal::FunctorTraits<void (cc::ScrollbarAnimationController::*)(), void>::Invoke<base::WeakPtr<cc::ScrollbarAnimationController>>(void (cc::ScrollbarAnimationController::*)(), base::WeakPtr<cc::ScrollbarAnimationController>&&) #28 0x7ffaa3b42779 void base::internal::InvokeHelper<true, void>::MakeItSo<void (base::CancelableCallback<void ()>::* const&)() const, base::WeakPtr<base::CancelableCallback<void ()> >>(void (base::CancelableCallback<void ()>::* const&)() const, base::WeakPtr<base::CancelableCallback<void ()> >) #29 0x7ffaa3b426ff void base::internal::Invoker<base::internal::BindState<void (base::CancelableCallback<void ()>::*)() const, base::WeakPtr<base::CancelableCallback<void ()> > >, void ()>::RunImpl<void (base::CancelableCallback<void ()>::* const&)() const, std::tuple<base::WeakPtr<base::CancelableCallback<void ()> > > const&, 0ul>(void (base::CancelableCallback<void ()>::* const&)() const, std::tuple<base::WeakPtr<base::CancelableCallback<void ()> > > const&, base::IndexSequence<0ul>) #30 0x7ffaa3b4259c base::internal::Invoker<base::internal::BindState<void (base::CancelableCallback<void ()>::*)() const, base::WeakPtr<base::CancelableCallback<void ()> > >, void ()>::Run(base::internal::BindStateBase*) #31 0x7ffaac12bd1e base::Callback<>::Run() #32 0x7ffaac14d99e base::debug::TaskAnnotator::RunTask() #33 0x7ffaac1c0451 base::MessageLoop::RunTask() #34 0x7ffaac1c06d4 base::MessageLoop::DeferOrRunPendingTask() #35 0x7ffaac1c099e base::MessageLoop::DoWork() #36 0x7ffaac1d723c base::MessagePumpLibevent::Run() #37 0x7ffaac1bfeba base::MessageLoop::RunHandler() #38 0x7ffaac259534 base::RunLoop::Run() #39 0x7ffaac1bf061 base::MessageLoop::Run() #40 0x7ffaace87940 MashRunner::StartChildApp() #41 0x7ffaace95c46 void base::internal::FunctorTraits<void (MashRunner::*)(mojo::InterfaceRequest<shell::mojom::Service>), void>::Invoke<MashRunner*, mojo::InterfaceRequest<shell::mojom::Service> >(void (MashRunner::*)(mojo::InterfaceRequest<shell::mojom::Service>), MashRunner*&&, mojo::InterfaceRequest<shell::mojom::Service>&&) #42 0x7ffaace95b76 void base::internal::InvokeHelper<false, void>::MakeItSo<void (MashRunner::* const&)(mojo::InterfaceRequest<shell::mojom::Service>), MashRunner*, mojo::InterfaceRequest<shell::mojom::Service> >(void (MashRunner::* const&)(mojo::InterfaceRequest<shell::mojom::Service>), MashRunner*&&, mojo::InterfaceRequest<shell::mojom::Service>&&) #43 0x7ffaace95b07 void base::internal::Invoker<base::internal::BindState<void (MashRunner::*)(mojo::InterfaceRequest<shell::mojom::Service>), base::internal::UnretainedWrapper<MashRunner> >, void (mojo::InterfaceRequest<shell::mojom::Service>)>::RunImpl<void (MashRunner::* const&)(mojo::InterfaceRequest<shell::mojom::Service>), std::tuple<base::internal::UnretainedWrapper<MashRunner> > const&, 0ul>(void (MashRunner::* const&)(mojo::InterfaceRequest<shell::mojom::Service>), std::tuple<base::internal::UnretainedWrapper<MashRunner> > const&, base::IndexSequence<0ul>, mojo::InterfaceRequest<shell::mojom::Service>&&) #44 0x7ffaace95a5c base::internal::Invoker<base::internal::BindState<void (MashRunner::*)(mojo::InterfaceRequest<shell::mojom::Service>), base::internal::UnretainedWrapper<MashRunner> >, void (mojo::InterfaceRequest<shell::mojom::Service>)>::Run(base::internal::BindStateBase*, mojo::InterfaceRequest<shell::mojom::Service>&&) #45 0x7ffaad157193 base::Callback<>::Run() #46 0x7ffaaf84f51d shell::ChildProcessMainWithCallback() #47 0x7ffaace87512 MashRunner::RunChild() #48 0x7ffaace873ef MashRunner::Run() #49 0x7ffaace87a34 MashMain() #50 0x7ffaace83136 ChromeMain #51 0x7ffaace830b2 main #52 0x7ffa99b1bf45 __libc_start_main #53 0x7ffaace82f94 <unknown> I suspect that either the bindings code should be able to handle empty quads lists, or the compositor is creating an invalid compositor frame.
,
Jul 11 2016
,
Jul 18 2016
I did a bisect and traced this down to ff18d775f07c5c2f8002dfe563f081427045a187, which was the initial commit of the RenderPass StructTraits. (https://codereview.chromium.org/2088603002)
,
Jul 18 2016
I think this is fixed? I thought Peng landed a fix in another bug?https://codereview.chromium.org/2136313002/
,
Jul 18 2016
I just pulled and rebuilt. It's fixed in the sense that it doesn't crash, but it only doesn't crash because it now non-fataly rejects the mojo message. ("Invalid message: VALIDATION_ERROR_DESERIALIZATION_FAILED").
,
Jul 18 2016
OK, so this is weird. On the receiving side, we're failing to deserialize...I think RenderPass. I added a base::debug::StackTrace() to the failure case in mojo::internal::Deserialize<>(). Here's the earliest one: #0 0x7fccb4807bee base::debug::StackTrace::StackTrace() #1 0x7fccb716f442 bool mojo::internal::Deserialize<mojo::StructPtr<cc::mojom::RenderPass>, cc::mojom::internal::RenderPass_Data*, std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >, mojo::internal::SerializationContext*&, (void*)0>(cc::mojom::internal::RenderPass_Data*&&, std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >*, mojo::internal::SerializationContext*&) #2 0x7fccb718ad9a mojo::internal::ArraySerializer<>::DeserializeElements() #3 0x7fccb718aca3 mojo::internal::Serializer<>::Deserialize() #4 0x7fccb718ac17 bool mojo::internal::Deserialize<mojo::Array<mojo::StructPtr<cc::mojom::RenderPass> >, mojo::internal::Array_Data<mojo::internal::Pointer<cc::mojom::internal::RenderPass_Data> >*&, std::__debug::vector<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >, std::allocator<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> > > >, mojo::internal::SerializationContext*&, (void*)0>(mojo::internal::Array_Data<mojo::internal::Pointer<cc::mojom::internal::RenderPass_Data> >*&, std::__debug::vector<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >, std::allocator<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> > > >*, mojo::internal::SerializationContext*&) #5 0x7fccb718a2d0 cc::mojom::CompositorFrameDataView::ReadPasses<>() #6 0x7fccb718a20f mojo::StructTraits<>::Read() #7 0x7fccb7122ec4 mojo::internal::Serializer<>::Deserialize() #8 0x7fccb7122e17 bool mojo::internal::Deserialize<mojo::StructPtr<cc::mojom::CompositorFrame>, cc::mojom::internal::CompositorFrame_Data*&, cc::CompositorFrame, mojo::internal::SerializationContext*&, (void*)0>(cc::mojom::internal::CompositorFrame_Data*&, cc::CompositorFrame*, mojo::internal::SerializationContext*&) #9 0x7fccb710aac0 ui::mojom::(anonymous namespace)::Surface_SubmitCompositorFrame_ParamsDataView::ReadFrame<>() #10 0x7fccb710a642 ui::mojom::SurfaceStub::AcceptWithResponder() #11 0x7fccb8e24299 mojo::internal::Router::HandleMessageInternal() #12 0x7fccb8e22da3 mojo::internal::Router::HandleIncomingMessage() However, we're actually successfully building this message in a debug build. If we're making invalid messages, why aren't we triggering MOJO_INTERNAL_DLOG_SERIALIZATION_WARNING() in the sender?
,
Jul 20 2016
I believe I found where the problem is in the deserialization code: https://codereview.chromium.org/2170603002/
,
Jul 20 2016
Unit test please :-)
,
Jul 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/878c8a7bea123af169b82bf5de31e8b4356ad47c commit 878c8a7bea123af169b82bf5de31e8b4356ad47c Author: erg <erg@chromium.org> Date: Thu Jul 21 17:35:54 2016 cc: Fix negative integer overflow in RenderPass serialization code. It is valid to submit a RenderPass with an empty |shared_quad_state_list|. We need to deal with this case so that we don't otherwise take size() - 1, which causes a negative integer overflow. BUG= 626771 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2170603002 Cr-Commit-Position: refs/heads/master@{#406893} [modify] https://crrev.com/878c8a7bea123af169b82bf5de31e8b4356ad47c/cc/ipc/render_pass_struct_traits.cc [modify] https://crrev.com/878c8a7bea123af169b82bf5de31e8b4356ad47c/cc/ipc/struct_traits_unittest.cc
,
Jul 21 2016
,
Aug 29 2016
,
Oct 7 2016
,
Nov 19 2016
,
Jan 21 2017
,
Mar 4 2017
,
Apr 17 2017
,
May 30 2017
,
Aug 1 2017
,
Oct 14 2017
,
Feb 26 2018
|
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by e...@chromium.org
, Jul 8 2016