"mash_browser_tests (with patch)" is flaky.
This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label.
We have detected 3 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyKgsSBUZsYWtlIh9tYXNoX2Jyb3dzZXJfdGVzdHMgKHdpdGggcGF0Y2gpDA.
At least one of the problems seems to be triggered by mus crashing. Stack is here:
#0 0x7f2c5ba902be base::debug::StackTrace::StackTrace()
#1 0x7f2c5ba97b7a logging::LogMessage::~LogMessage()
#2 0x7f2c5c005d42 ui::ws::WindowTree::NewTopLevelWindow()
#3 0x7f2c5b93ceba ui::mojom::WindowTreeStub::Accept()
#4 0x7f2c5bb0ec34 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#5 0x7f2c5b941dec ui::mojom::WindowTreeRequestValidator::Accept()
#6 0x7f2c5bb0f9fa mojo::InterfaceEndpointClient::HandleIncomingMessage()
#7 0x7f2c5bb14017 mojo::internal::MultiplexRouter::ProcessIncomingMessage()
#8 0x7f2c5bb12d25 mojo::internal::MultiplexRouter::ProcessTasks()
#9 0x7f2c5bb149d2 mojo::internal::MultiplexRouter::LockAndCallProcessTasks()
#10 0x7f2c5ba907d9 base::debug::TaskAnnotator::RunTask()
#11 0x7f2c5ba9ce25 base::MessageLoop::RunTask()
#12 0x7f2c5ba9d118 base::MessageLoop::DeferOrRunPendingTask()
#13 0x7f2c5ba9d46b base::MessageLoop::DoWork()
#14 0x7f2c5ba9ed49 base::MessagePumpGlib::Run()
#15 0x7f2c5ba9c96d base::MessageLoop::RunHandler()
#16 0x7f2c5baad190 base::RunLoop::Run()
#17 0x7f2c5ba8827b shell::ApplicationRunner::Run()
#18 0x7f2c5ba8832c shell::ApplicationRunner::Run()
#19 0x7f2c5b913d58 MojoMain
#20 0x000002b99204 shell::RunNativeApplication()
#21 0x000002b96750 shell::(anonymous namespace)::RunNativeLibrary()
#22 0x000001febc8a _ZN4base8internal7InvokerINS0_9BindStateIPFvPN7content15RenderFrameHostEN4mojo16InterfaceRequestIN5blink5mojom19PresentationServiceEEEEJNS0_17UnretainedWrapperINS3_19RenderFrameHostImplEEEEEEFvSB_EE3RunEPNS0_13BindStateBaseEOSB_
#23 0x000002b9813b shell::ChildProcessMainWithCallback()
#24 0x000002b966f6 shell::ChildProcessMain()
#25 0x000001522585 RunMashBrowserTests()
#26 0x0000005ffbc3 main
#27 0x7f2c5def47ed __libc_start_main
#28 0x0000005ffad1 <unknown>
This DCHECK will only hit if a binding has been paused *and* we are still getting messages. I asked Yuzhu about it and he is going to take a look.
RE comment #5: If the MultplexRouter has queued an incoming message before we pause the underlying message pipe, then it is possible to dispatch it to the user code. However, according to Scott this message pipe hasn't served any associated interface yet and no sync method call is possible. In that case, I don't know why we need to queue incoming messages.
I will need to take a closer look.
Btw, is this flake new? I followed the link on comment #3 and clicked "show all flakes" at the bottom. The oldest is 2016-07-07. I am not familiar with this tool -- does it only cache data for a few days? If not, this is likely to be a regression.
Comment 1 by chromium...@appspot.gserviceaccount.com
, Jul 13 2016