+msw@: As an owner of c/b/ui, can you help triage this issue?

Thanks!

It seems like this test times out and then passes for every run of mash_browser_tests:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=mash_browser_tests&tests=BrowserTest.JavascriptAlertActivatesTab
For example: https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.chromiumos%2FLinux_ChromiumOS_Ozone_Tests__1_%2F45021%2F%2B%2Frecipes%2Fsteps%2Fmash_browser_tests%2F0%2Fstdout

Unfortunately, it also seems like there is a high rate of numerous mash_browser_tests timing out and then passing.

In that latest run, all these tests timed out and then passed on retry:
[41/46] BrowserTest.CanDuplicateTab (1832 ms)
[42/46] BrowserTest.ClearPendingOnFailUnlessNTP (2094 ms)
[43/46] BrowserTest.DefaultMediaDevices (2094 ms)
[44/46] BrowserTest.GetSizeForNewRenderView (2619 ms)
[45/46] BrowserTest.JavascriptAlertActivatesTab (2880 ms)
[46/46] BrowserTest.Title (2356 ms)

In the prior run, it was a mostly-overlapping set (+AboutVersion, -DefaultMediaDevices) of these 6 tests:
[41/46] BrowserTest.AboutVersion (2356 ms)
[42/46] BrowserTest.CanDuplicateTab (2357 ms)
[43/46] BrowserTest.ClearPendingOnFailUnlessNTP (1832 ms)
[44/46] BrowserTest.GetSizeForNewRenderView (2619 ms)
[45/46] BrowserTest.JavascriptAlertActivatesTab (3143 ms)
[46/46] BrowserTest.Title (2619 ms)

Jon, how were the tests selected for https://codereview.chromium.org/2776453005 ?
We'll need to quickly track down the cause of these flakes, or exclude a bunch of tests.

Sadly, even BrowserTest.Title started flaking around 3/14/2017 6:44:30 PM PDT (r456510 to r456929):
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=mash_browser_tests&tests=BrowserTest.Title
Here's my attempt to reconstruct that revision range without having access to the build log:
https://chromium.googlesource.com/chromium/src/+log/878b2e67ac952b00b2fcafc54867f61b25507923..a1a5ce8907afdad37a43b5fafc266be318aa491a?pretty=fuller

The earliest CL in that range is actually a PlzNavigate timing fix (perhaps not actually related...):
https://chromium.googlesource.com/chromium/src/+/878b2e67ac952b00b2fcafc54867f61b25507923

The fact that even the original test we had running "BrowserTest.Title" has been flaky concerns me.

As for how I enabled them: I ran the entire BrowserTest set locally, and then didn't whitelist tests that failed. When they also passed on the trybot I landed them.

I'm working on expanding the tests further, and locally have been seeing lots of tests time out. So I've been building a blacklist for them. However too many fail right now before a retest phase, so I don't know if that is the same behaviour.

If these flakes are causing issues for the CQ then I can lend a blacklist for them. While the root cause is investigated.

One of the test runs shows a stack trace. Not sure yet if this is causing timeouts to be hit. The test suite may be in a bad state, and the timeouts due to this:

https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_chromeos_ozone_rel_ng/builds/352353

#0 0x00000366e917 base::debug::StackTrace::StackTrace()
#1 0x0000036864da logging::LogMessage::~LogMessage()
#2 0x000004d03970 gpu::SyncPointOrderData::BeginProcessingOrderNumber()
#3 0x000004d3f2bc gpu::InProcessCommandBuffer::ProcessTasksOnGpuThread()
#4 0x000000738998 _ZN4base8internal7InvokerINS0_9BindStateIMN12_GLOBAL__N_116SimpleHttpServer10ConnectionEFvvEJNS_7WeakPtrIS5_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#5 0x0000006a2f24 _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE1ELNS2_10RepeatModeE1EE3RunEv
#6 0x0000037189aa base::debug::TaskAnnotator::RunTask()
#7 0x00000368dc1d base::MessageLoop::RunTask()
#8 0x00000368deb8 base::MessageLoop::DeferOrRunPendingTask()
#9 0x00000368e2a6 base::MessageLoop::DoWork()
#10 0x00000368fc59 base::MessagePumpDefault::Run()
#11 0x00000368d99a base::MessageLoop::RunHandler()
#12 0x0000036b488f base::RunLoop::Run()
#13 0x0000036de4ab base::Thread::Run()
#14 0x0000036de96e base::Thread::ThreadMain()
#15 0x0000036d7a4c base::(anonymous namespace)::ThreadFunc()
#16 0x7f9609f93184 start_thread
#17 0x7f96066ef37d clone

Received signal 6
#0 0x00000366e917 base::debug::StackTrace::StackTrace()
#1 0x00000366e48f base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f9609f9b330 <unknown>
#3 0x7f960662bc37 gsignal
#4 0x7f960662f028 abort
#5 0x00000366d1b2 base::debug::BreakDebugger()
#6 0x0000036867cb logging::LogMessage::~LogMessage()
#7 0x000004d03970 gpu::SyncPointOrderData::BeginProcessingOrderNumber()
#8 0x000004d3f2bc gpu::InProcessCommandBuffer::ProcessTasksOnGpuThread()
#9 0x000000738998 _ZN4base8internal7InvokerINS0_9BindStateIMN12_GLOBAL__N_116SimpleHttpServer10ConnectionEFvvEJNS_7WeakPtrIS5_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#10 0x0000006a2f24 _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE1ELNS2_10RepeatModeE1EE3RunEv
#11 0x0000037189aa base::debug::TaskAnnotator::RunTask()
#12 0x00000368dc1d base::MessageLoop::RunTask()
#13 0x00000368deb8 base::MessageLoop::DeferOrRunPendingTask()
#14 0x00000368e2a6 base::MessageLoop::DoWork()
#15 0x00000368fc59 base::MessagePumpDefault::Run()
#16 0x00000368d99a base::MessageLoop::RunHandler()
#17 0x0000036b488f base::RunLoop::Run()
#18 0x0000036de4ab base::Thread::Run()
#19 0x0000036de96e base::Thread::ThreadMain()
#20 0x0000036d7a4c base::(anonymous namespace)::ThreadFunc()
#21 0x7f9609f93184 start_thread
#22 0x7f96066ef37d clone
  r8: ffffaccccef85f78  r9: ffffaccccef85f68 r10: 0000000000000008 r11: 0000000000000202
 r12: 0000000000000000 r13: 00002c62ce037000 r14: 00007f96045e6928 r15: 00007f96045e6918
  di: 000000000000030d  si: 0000000000000335  bp: 00002c62cf51e5e0  bx: 0000000000000000
  dx: 0000000000000006  ax: 0000000000000000  cx: ffffffffffffffff  sp: 00007f96045e6358
  ip: 00007f960662bc37 efl: 0000000000000202 cgf: 0000000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]

That looks like something is bad in the gpu/cc side of things.

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

commit f7e1bdb4694eb8114f9ccfbf4b4f0efac3caa4a1
Author: jonross <jonross@chromium.org>
Date: Fri Mar 31 20:13:07 2017

Disable Flaky mash_browser_tests

Disabling tests that are being reported as flaky, until the root cause can be
determined.

TEST=mash_browser_tests
BUG= 707195 

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

[modify] https://crrev.com/f7e1bdb4694eb8114f9ccfbf4b4f0efac3caa4a1/testing/buildbot/filters/mash.browser_tests.filter

Removing from sheriff queue since flaky tests have been disabled.

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

commit ff40c5c797428e560b98b3390a81d5c19eadd8f0
Author: Jonathan <jonross@chromium.org>
Date: Tue Jul 18 15:06:10 2017

Reenable some BrowserTests on FYI bots

Some of the BrowserTest suite was flaky, and disabled. The various sources of
the flakes have been since addressed. I'm turning them back on the FYI bot to
verify.

TBR=sky@chromium.org
TEST=BrowserTest in mash_browser_tests

Bug:  707195 
Change-Id: I36f3bf2c98135842a68217b6bf2982065f9dec3b
Reviewed-on: https://chromium-review.googlesource.com/574613
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487472}
[modify] https://crrev.com/ff40c5c797428e560b98b3390a81d5c19eadd8f0/testing/buildbot/filters/mojo.fyi.browser_tests.filter