pcc@, I understand you are involved with the Linux_CFI bot?

I have a browser_test that is flaky in Linux_CFI - but no other bot that I am aware of. 

Would you mind assessing whether this test is causing a CFI failure, or if it is just some other randomness that is only causing a failure on this bot?  That would be appreciated.

Here is an example of a recent Linux_CFI failure.

https://logs.chromium.org/v/?s=chromium%2Fbb%2Fchromium.memory%2FLinux_CFI%2F6597%2F%2B%2Frecipes%2Fsteps%2Fbrowser_tests%2F0%2Flogs%2FMediaRouterIntegrationBrowserTest.Basic%2F0

I'm going to disable the test for now.

I will take a look.

Would you mind providing a few details about what this test does? It looks like it spawns a new process and communicates with it, is that accurate?

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

commit 54b2402cbdf82422ad9ae5b798acfc6f4b751a23
Author: mark a. foltz <mfoltz@chromium.org>
Date: Wed Mar 21 21:31:34 2018

Media Router: Disable MediaRouterIntegrationBrowserTest.Basic.

This test is flaky on the Linux_CFI bot.

TBR=imcheng

Bug:  822337 
Change-Id: I65b5eb16c71e43a57dad248deba22b970784f603
Reviewed-on: https://chromium-review.googlesource.com/974162
Reviewed-by: mark a. foltz <mfoltz@chromium.org>
Commit-Queue: mark a. foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544853}
[modify] https://crrev.com/54b2402cbdf82422ad9ae5b798acfc6f4b751a23/chrome/test/media_router/media_router_integration_browsertest.cc

pcc@: The test starts a browser process, and loads a page into a tab that tries to start a Cast session (PresentationRequest.start()).

https://cs.chromium.org/chromium/src/chrome/test/media_router/media_router_integration_browsertest.cc?rcl=faf8f15004bf40ab250cb04c958dcfa96705f8f8&l=639

This brings up a WebUI dialog, which the test injects script into to mimic the user selecting a Cast device.

That in turn, starts a fake Cast session.  The page then requests that the session be stopped (via Javascript).

That last action seems to be triggering the test failure, since the Mojo callback for the request is not being handled.   We're investigating similar failures in other test cases, but was wondering if there was anything specific about Linux_CFI that might be relevant here.

Removing from the general sheriff queue. If that's wrong, add it back :)

The Linux CFI bot builds binaries with additional checks for things like virtual calls and casts on uninitialized and freed memory.

I can (non-deterministically) repro locally with the config on the bot. I can also repro (but much less frequently) in the same configuration but with LTO and CFI related flags removed, i.e.

dcheck_always_on = true
is_component_build = false
is_debug = false
strip_absolute_paths_from_debug_symbols = true
use_goma = true

It's possible that the additional checks in the CFI build are provoking the race condition into happening more often.

Thanks, it sounds like CFI is triggering the nondeterminism more frequently in this test.  We'll take it from here.