New issue
Advanced search Search tips

Issue 728034 link

Starred by 0 users
Status: Assigned
Owner:
skyos...@chromium.org
Cc:
tmonius...@opera.com
gab@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

RenderThreadImplBrowserTest.InputHandlerManagerDestroyedAfterCompositorThread is flaky on Windows

Project Member Reported by kjellander@chromium.org, May 31 2017 
The RenderThreadImplBrowserTest.InputHandlerManagerDestroyedAfterCompositorThread test started to flake around https://build.chromium.org/p/chromium.win/builders/Win%207%20Tests%20x64%20%281%29/builds/24771 according to https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=content_browsertests&tests=RenderThreadImplBrowserTest.InputHandlerManagerDestroyedAfterCompositorThread

I'm unable to find a culprit CL after looking at the blamelists for that build and the ones before. The error only seems to fire every 5 builds or so.

Assigning to skyostil@chromium.org for further triage after looking at git blame.
Project Member

Comment 1 by bugdroid1@chromium.org, May 31 2017 

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

commit 0c0fcbe9055460e377217cfe6694f8ce1a2d4eeb
Author: Henrik Kjellander <kjellander@chromium.org>
Date: Wed May 31 07:36:15 2017

Disable InputHandlerManagerDestroyedAfterCompositorThread on Windows

The test RenderThreadImplBrowserTest.InputHandlerManagerDestroyedAfterCompositorThread
is flaky on Windows, with first obvservation being
https://build.chromium.org/p/chromium.win/builders/Win%207%20Tests%20x64%20%281%29/builds/24771

BUG=728034
TBR=skyostil@chromium.org

Change-Id: Icf3a073407eb8eaa13c111987544d887bcac68ca
Reviewed-on: https://chromium-review.googlesource.com/518822
Reviewed-by: Henrik Kjellander <kjellander@chromium.org>
Commit-Queue: Henrik Kjellander <kjellander@chromium.org>
Cr-Commit-Position: refs/heads/master@{#475839}
[modify] https://crrev.com/0c0fcbe9055460e377217cfe6694f8ce1a2d4eeb/content/renderer/render_thread_impl_browsertest.cc

Comment 2 by tmonius...@opera.com, Jun 6 2017

Cc: gab@chromium.org
I think it has been introduced by https://bugs.chromium.org/p/chromium/issues/detail?id=724086. CHECK(base::MessageLoop::current()->IsIdleForTesting()) no longer fires for me if I revert this CL.

Comment 3 by gab@chromium.org, Jun 6 2017 

How are you repro'ing the flake? I just re-enabled the test locally and it passed all --gtest_repeat=50 iterations.

The first observation is reported to be at r475633, my CL landed at r472864 a full 12 days earlier.

Shall we try to re-enable?

Comment 4 by gab@chromium.org, Jun 6 2017 

If it matters, I'm on Win10(64bit) with GN args:

target_cpu = "x86"
is_component_build = true
is_debug = true
dcheck_always_on = true
enable_nacl = false
is_clang = false
is_chrome_branded = false

Comment 5 by tmonius...@opera.com, Jun 7 2017 

I'm only able to reproduce it in Release mode. It's not reproducible in Debug.

I'm on Win 7. GN args for build:
is_debug = false
is_component_build = false
target_cpu = "x64"
enable_nacl = false
symbol_level = 0

I'm just running:
content_browsertests.exe --gtest_filter=RenderThreadImplBrowserTest.InputHandlerManagerDestroyedAfterCompositorThread

The CHECK is fired in ~80% of runs for me.

Comment 6 by tmonius...@opera.com, Jun 7 2017

Cc: tmonius...@opera.com

Comment 7 by nzolghadr@chromium.org, Jan 7 

skyostil@ any action item here for this bug?
►

Sign in to add a comment