New issue
Advanced search Search tips

Issue 749366 link

Starred by 2 users

Issue metadata

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



Sign in to add a comment

LayerTreeHostImplTest.GPUMemoryForLargeLayerHistogramTest flake

Project Member Reported by vmp...@chromium.org, Jul 27 2017

Issue description

I've only seen this trigger once, so I'm not sure what's wrong, but here's what I got:

[ RUN      ] LayerTreeHostImplTest.GPUMemoryForLargeLayerHistogramTest
[5685:5685:0726/180233.734970:10989330024100:WARNING:histograms.cc(40)] Started multiple compositor clients (Renderer, Browser) in one process. Some metrics will be disabled.
../../base/test/histogram_tester.cc:55: Failure
Expected: (nullptr) != (histogram), actual: 8-byte object <00-00 00-00 00-00 00-00> vs NULL
Histogram "Compositing.Browser.GPUMemoryForTilingsInKb" does not exist.
../../base/test/histogram_tester.cc:72: Failure
      Expected: count
      Which is: 1
To be equal to: 0
Histogram "Compositing.Browser.GPUMemoryForTilingsInKb" does not exist.
[  FAILED  ] LayerTreeHostImplTest.GPUMemoryForLargeLayerHistogramTest (53 ms)
 

Comment 1 by yigu@chromium.org, Jul 27 2017

As the warning msg says, when running two clients in one process, the second test will fail because there is no corresponding process for the second client therefore the second metric does not exist. I suppose this is expected? Or is there a way to avoid running two clients in one process in the test?

Comment 2 by vmp...@chromium.org, Jul 27 2017

You're right that this is an "expected" failure. The problem is that this line for example makes it reproduce 100% of the time:

./out/Debug/cc_unittests --single-process-tests --gtest_filter="LayerTreeHostImplTest.GPUMemoryForSmallLayerHistogramTest:LayerTreeHostImplTest.GPUMemoryForLargeLayerHistogramTest"

In non-single-process tests, there's probably a good chance that the two tests will run in a same process. I think the test suite buckets about 10 tests in each process, and since these are next to each other I think they may be good candidates to run in the same process.

One possibility is that we should add something along the lines of ResetClientNameForMetricsForTesting(); which each of the tests will call and it will just clear out g_client_name, so that the next call to SetClientNameForMetrics would think that it's setting the client name for the first time. Since the tests are run in the same thread, but maybe multiple processes then this should work?

Comment 3 by yigu@chromium.org, Jul 28 2017

Cc: yigu@chromium.org
 Issue 750377  has been merged into this issue.
Project Member

Comment 4 by bugdroid1@chromium.org, Jul 31 2017

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

commit 6a75e23e745659e22e3192a2e504478d4ea509f5
Author: Yi Gu <yigu@chromium.org>
Date: Mon Jul 31 17:10:37 2017

Only test the renderer process when recording GPU memory cost

In non-single-process tests, there's a good chance that two unit tests
running in the same process need to set different client names.
Currently whichever comes second cannot set the client name correctly.

However, there is no ideal way to test both processes. Resetting the
client names in the test doesn't work because the histogram has static
client name which invalidates the name resetting. To fix, it requires
confusing work-around in the code therefore we prefer to test only one
process after all the logic is almost identical.

Bug:  749366 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iebd312e1138292754f4aa2aa1875b13365e5602f
Reviewed-on: https://chromium-review.googlesource.com/590172
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Commit-Queue: Yi Gu <yigu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490778}
[modify] https://crrev.com/6a75e23e745659e22e3192a2e504478d4ea509f5/cc/trees/layer_tree_host_impl_unittest.cc

Comment 5 by yigu@chromium.org, Jul 31 2017

Status: Fixed (was: Assigned)

Sign in to add a comment