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

Issue 703263 link

Starred by 9 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug


Sign in to add a comment

Flaky compositing tests [meta]

Project Member Reported by enne@chromium.org, Mar 20 2017

Issue description

In a linux asan build:
  is_debug = false
  is_component_build = true
  use_goma = true
  is_asan = true
  enable_nacl = false
  dcheck_always_on = true

...a number of cc_unittests appear to flake for me (collected over a bunch of runs):

LayerTreeHostCopyRequestTestLayerDestroyed.RunSingleThread_DelegatingRenderer
LayerTreeHostTestBeginFrameSequenceNumbers.RunMultiThread_DelegatingRenderer
LayerTreeHostTestBreakSwapPromiseForVisibility.RunSingleThread_DelegatingRenderer
LayerTreeHostTestSetVisible.RunMultiThread_DelegatingRenderer
LayerTreeHostTestStartPageScaleAnimation.RunMultiThread_DelegatingRenderer
LayerTreeHostTilesTestPartialInvalidation.FullRaster_MultiThread_OneCopy
LayerTreeHostTilesTestPartialInvalidation.PartialRaster_MultiThread_OneCopy
LayerTreeHostTilesTestPartialInvalidation.PartialRaster_SingleThread_GpuRaster
SurfaceLayerSwapPromiseWithDraw.RunSingleThread_DelegatingRenderer
UIResourceLostBeforeCommit.RunSingleThread_DelegatingRenderer

Here's a few examples:

[ RUN      ] SurfaceLayerSwapPromiseWithDraw.RunSingleThread_DelegatingRenderer
=================================================================
==3817==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f2ce4e45c70 at pc 0x000000657fe4 bp 0x7ffe7e3d7ee0 sp 0x7ffe7e3d7690

[ RUN      ] LayerTreeHostTestBreakSwapPromiseForVisibility.RunSingleThread_DelegatingRenderer
../../cc/trees/layer_tree_host_unittest.cc:4500: Failure
Value of: result_->did_not_swap_called
  Actual: true
Expected: false

[ RUN      ] LayerTreeHostCopyRequestTestLayerDestroyed.RunSingleThread_DelegatingRenderer
../../cc/trees/layer_tree_host_unittest_copyrequest.cc:236: Failure
Value of: result->IsEmpty()
  Actual: true
Expected: false


The partial invalidation tests have 100% incorrect bitmaps (according to the output).

I only saw the other issues once and didn't grab their stack traces.
 

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

Cc: dimaa@chromium.org sadrul@chromium.org
It looks like the error is in SurfaceLayerTest.SurfaceInfoPushProperties. This test itself passes, but it causes a crash in a subsequent test in the batch (SurfaceLayerSwapPromiseWithDraw.RunSingleThread_DelegatingRenderer). This happens because the test sets things up in a way that causes a stack-use-after-return. Specifically, the TestSurfaceReferenceFactory instance holds onto pointers to variables in the stack, and it looks like it continues to be used after the local stack unwinds.

The following change gets rid of this crash for me (locally):

diff --git a/cc/layers/surface_layer_unittest.cc b/cc/layers/surface_layer_unittest.cc
index ff787087015b..0ee83b1695ac 100644
--- a/cc/layers/surface_layer_unittest.cc
+++ b/cc/layers/surface_layer_unittest.cc
@@ -197,6 +197,8 @@ TEST_F(SurfaceLayerTest, SurfaceInfoPushProperties) {
   // SurfaceInfo is pushed through.
   EXPECT_EQ(primary_info, layer_impl->primary_surface_info());
   EXPECT_EQ(fallback_info, layer_impl->fallback_surface_info());
+  layer_tree_host_.reset();
+  base::RunLoop().RunUntilIdle();
 }
 
 // Check that SurfaceSequence is sent through swap promise.

Not sure if this is a good fix though.

Comment 2 by brettw@chromium.org, Apr 19 2017

SurfaceLayerSwapPromiseWithDraw.RunSingleThread_DelegatingRenderer seems to be flaky in non-ASAN also. See  issue 713255 .

Comment 3 by danakj@chromium.org, Apr 19 2017

I'm sure all of them are flaky under non-ASAN it only changes timing.

Comment 4 by danakj@chromium.org, Apr 19 2017

Blockedon: 713255

Comment 5 by brettw@chromium.org, Apr 19 2017

Blockedon: 713257
I filed  issue 713257  for LayerTreeHostTestStartPageScaleAnimation.RunMultiThread_DelegatingRenderer which I'm also seeing.

Comment 6 by danakj@chromium.org, Apr 19 2017

Cc: enne@chromium.org ccameron@chromium.org vmi...@chromium.org khushals...@chromium.org
 Issue 567439  has been merged into this issue.

Comment 7 by samans@chromium.org, Apr 19 2017

What sadrul said makes sense. Satisfying sequences is PostTasked in SurfaceLayer, so the test could end and the TestSurfaceReferenceFactory will be kept alive by the task. RunUntilIdle is not too bad; we already do it in MultipleFramesOneSurface. However, a better solution could be not passing pointers to TestSurfaceReferenceFactory at all. We can keep the values internally and add getters, or make TestSurfaceReferenceFactory a mock altogether and use EXPECT_CALL.

Comment 8 by samans@chromium.org, Apr 19 2017

Cc: samans@chromium.org
Project Member

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

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

commit 76209400f9091745a4ecc635223c5e9a86c96939
Author: samans <samans@chromium.org>
Date: Thu Apr 20 22:12:06 2017

Replace TestSurfaceReferenceFactory in surface_layer_unittests.cc with a mock implementation

TestSurfaceReferneceFactory currently takes pointers to stack variables
of a test and apparently writes to them when the stack is gone. This
has caused flakiness on some bots. A mock interface allows us to avoid
doing the nasty stuff with pointers and is generally nicer.

BUG=703263

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/76209400f9091745a4ecc635223c5e9a86c96939/cc/layers/surface_layer_unittest.cc

UIResourceLostBeforeCommit.RunSingleThread_DelegatingRenderer appeared to flake indeppendently on Windows :


/chromium.win/builders/Win7%20Tests%20%28dbg%29%281%29/builds/61178
where ...77 & ...79 passed.  None of the CLs in r out look likely to me, FWIW.
Do you have a stack trace or something?
Blockedon: 769344 778404 784563 707711
Cc: gklassen@chromium.org fsam...@chromium.org piman@chromium.org
I'm going to add blockers for known flaky tests. File sub bugs for any new tests instead of just a comment here.
Summary: Flaky compositing tests [meta] (was: cc_unittests flaky under ASAN)
Blockedon: 783283
Blockedon: 709080
 Issue 504052  has been merged into this issue.
Blockedon: 504087
Blockedon: 608436
Blockedon: 386199
Blockedon: 657910
Blockedon: 787871

Comment 22 by xing...@intel.com, Dec 1 2017

Blockedon: 790877
Blockedon: 803532
Blockedon: 813924
Blockedon: 822473
Blockedon: 834613
Blockedon: 848994
Blockedon: 855532 855533
Project Member

Comment 29 by bugdroid1@chromium.org, Jul 24

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

commit 586af386595943856c00e3d78f720dfa3d82d53a
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Tue Jul 24 21:44:38 2018

Do not call IsActiveTree() in LayerTreeImpl destructor

IsActiveTree() indirectly calls active_tree_.get() in LayerTreeHostImpl.
Since std::unique_ptr::reset() nulls out its ptr before deleting the
owned object, IsActiveTree() will always be false, and the swap promises
will always be broken with ACTIVATION_FAILS. This causes
LayerTreeHostTestSwapPromiseDuringCommit to fail when the wait for main
frame or commit condition is removed from LayerTreeTest::EndTest().

R=danakj
BUG=703263

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3819f76ab8f576c80faccf8db3ecd7ddb9b5954d
Reviewed-on: https://chromium-review.googlesource.com/1145920
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577696}
[modify] https://crrev.com/586af386595943856c00e3d78f720dfa3d82d53a/cc/trees/layer_tree_impl.cc

Sign in to add a comment