New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 702868 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

TextureLayerChangeInvisibleMailboxTest.RunMultiThread_DelegatingRenderer is flaky

Project Member Reported by pdr@chromium.org, Mar 18 2017

Issue description

TextureLayerChangeInvisibleMailboxTest.RunMultiThread_DelegatingRenderer is flaky and fails with the following:
../../cc/layers/texture_layer_unittest.cc:1195: Failure
Value of: 5
Expected: commit_count_
Which is: 4

This flake happens most on android but I can reliably reproduce it locally (OSX) with:
./out/Debug/cc_unittests --gtest_filter=TextureLayerChangeInvisibleMailboxTest.RunMultiThread_DelegatingRenderer --single-process-tests --gtest_break_on_failure --gtest_repeat=1000
It sometimes takes a few runs of this for the crash to reproduce.

A history of these flakes can be found in:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=cc_unittests&tests=TextureLayerChangeInvisibleMailboxTest.RunMultiThread_DelegatingRenderer

The most recent flake was:
https://build.chromium.org/p/chromium.linux/builders/Android%20Tests/builds/39440

This line changed recently. I think this is a regression from:
https://chromium.googlesource.com/chromium/src/+/5dbd77c73cd8a5f42762c5036a9860bc729dc359

An attempt to deflake this failure was landed in:
https://chromium.googlesource.com/chromium/src/+/0834fe043155e4fa29304939380d5b90a3ad3658
 

Comment 1 by samans@chromium.org, Mar 20 2017

Cc: piman@chromium.org fsam...@chromium.org danakj@chromium.org enne@chromium.org samans@chromium.org
 Issue 700956  has been merged into this issue.

Comment 3 by danakj@chromium.org, Mar 28 2017

samans@ are you working on this still, or should we revert while we sort it out? This affects all chrome developers and our infra

Comment 4 by samans@chromium.org, Mar 28 2017

Sorry for the delay addressing this issue. I was busy with some other tasks. I'm going to prioritize this, but if you'd like I can disable this test for now?

Comment 5 by st...@chromium.org, Apr 4 2017

Labels: -AnalyzedByFindit Test-Findit-Analyzed
Labels: Sheriff-Chromium
Project Member

Comment 7 by bugdroid1@chromium.org, Apr 5 2017

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

commit 3d6b9c4446803f39225f7bcfeb46c8adcb6570d2
Author: maxmorin <maxmorin@chromium.org>
Date: Wed Apr 05 10:41:14 2017

Disable flaky TextureLayerChangeInvisibleMailboxTest.

BUG= 702868 
TBR=enne@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/3d6b9c4446803f39225f7bcfeb46c8adcb6570d2/cc/layers/texture_layer_unittest.cc

Labels: -Sheriff-Chromium
Project Member

Comment 9 by bugdroid1@chromium.org, Apr 19 2017

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

commit 44b6dfc95bd4a7b8240b81720b9804692b439ae9
Author: samans <samans@chromium.org>
Date: Wed Apr 19 16:50:53 2017

Fixing flakiness of TextureLayerChangeInvisibleMailboxTest

The flake seems to be because of a race between the order of running main and impl
thread. Resources are always reclaimed after impl threads posts
DidCommitAndDrawFrame to the main thread so whether commit_count_ == 4 or 5
depends on whether we switch to main thread or keep running impl thread and
reclaim resources which triggers posting a task to the main thread to release the
mailbox. Even though the task for DidCommitAndDrawFrame is posted first, the task
for releasing mailbox is posted using a blocking task runner so it is run first.
In order to solve this issue, we decided to use
DidReceiveCompositorFrameAck instead of DidCommitAndDrawFrame because
all the resources are released before DidReceiveCompositorFrameAck is
called so the race between releasing resources and starting next commit
doesn't happen. In single-thread mode we used to call
DidReceiveCompositorFrameAck directly instead of PostTasking which
caused different behaviour from multi-thread mode. We decided to also
use PostTask for DidReceiveCompositorFrameAck in single thread mode and
use weak pointers to discard the ack if CompositorFrameSink is released
before ack is processed.

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
BUG= 702868 

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

[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/layers/texture_layer_unittest.cc
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/test/layer_tree_test.cc
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/test/test_hooks.h
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/trees/layer_tree_host_unittest.cc
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/trees/proxy_impl.cc
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/trees/proxy_impl.h
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/trees/proxy_main.cc
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/trees/proxy_main.h
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/trees/single_thread_proxy.cc
[modify] https://crrev.com/44b6dfc95bd4a7b8240b81720b9804692b439ae9/cc/trees/single_thread_proxy.h

Status: Fixed (was: Assigned)
Components: -Internals>MUS Internals>Services>WindowService

Sign in to add a comment