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

Issue 839861 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

OOPBrowserTest.Basic Flaky on ASAN Bots

Project Member Reported by jonr...@chromium.org, May 4 2018

Issue description

I'd seen a few flakes of OOPBrowserTest.Basic so I decided to look it up in the flakiness dashboard:

https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=content_browsertests&tests=OOPBrowserTest.Basic

There are fairly regular flakes on both Linux ChromeOS and Mac ASan bots.

The most recent Mac failure to ping sheriffs was:
https://ci.chromium.org/buildbot/chromium.memory/Mac%20ASan%2064%20Tests%20%281%29/40472

With an error stack of:

[56648:775:0504/063324.002376:WARNING:vt_video_decode_accelerator_mac.cc(177)] Failed to create VTDecompressionSession: Error Domain=NSOSStatusErrorDomain Code=-8973 "codecOpenErr" (-8973)
[56648:775:0504/063324.003452:WARNING:vt_video_decode_accelerator_mac.cc(199)] Failed to create hardware VideoToolbox session
[56648:775:0504/063324.095289:ERROR:vt_video_encode_accelerator_mac.cc(516)]  VTCompressionSessionCreate failed: -12908
../../content/browser/oop_browsertest.cc:67: Failure
Value of: rwh->GetView()->IsSurfaceAvailableForCopy()
  Actual: false
Expected: true
Stack trace:
0   content_browsertests                0x0000000110788512 testing::internal::UnitTestImpl::CurrentOsStackTraceExceptTop(int) + 242
1   content_browsertests                0x00000001107870f7 testing::internal::AssertHelper::operator=(testing::Message const&) const + 359
2   content_browsertests                0x000000010e5f5296 content::(anonymous namespace)::OOPBrowserTest_Basic_Test::RunTestOnMainThread() + 2262
3   content_browsertests                0x0000000115a4acb8 content::BrowserTestBase::ProxyRunTestOnMainThreadLoop() + 1496
4   content_browsertests                0x0000000115c707a8 content::ShellBrowserMainParts::PreMainMessageLoopRun() + 824
5   content_browsertests                0x0000000113f9bb33 content::BrowserMainLoop::PreMainMessageLoopRun() + 355
6   content_browsertests                0x0000000114f4680f content::StartupTaskRunner::RunAllTasksNow() + 415
7   content_browsertests                0x0000000113f9792a content::BrowserMainLoop::CreateStartupTasks() + 1850
8   content_browsertests                0x0000000113fa34bf content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const&) + 463
9   content_browsertests                0x0000000115c6ed96 ShellBrowserMain(content::MainFunctionParams const&, std::__1::unique_ptr<content::BrowserMainRunner, std::__1::default_delete<content::BrowserMainRunner> > const&) + 278
10  content_browsertests                0x0000000115b7cbe7 content::ShellMainDelegate::RunProcess(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, content::MainFunctionParams const&) + 743
11  content_browsertests                0x0000000113bbaea0 content::RunNamedProcessTypeMain(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, content::MainFunctionParams const&, content::ContentMainDelegate*) + 1248
12  content_browsertests                0x0000000113bbcb23 content::ContentMainRunnerImpl::Run() + 1315
13  content_browsertests                0x000000011a85cc41 service_manager::Main(service_manager::MainParams const&) + 5377
14  content_browsertests                0x00000001113df011 content::ContentMain(content::ContentMainParams const&) + 353
15  content_browsertests                0x0000000115a498e9 content::BrowserTestBase::SetUp() + 6057
16  content_browsertests                0x0000000115a12d80 content::ContentBrowserTest::SetUp() + 1376
[56644:23043:0504/063324.871656:WARNING:discardable_shared_memory_manager.cc(431)] Some MojoDiscardableSharedMemoryManagerImpls are still alive. They will be leaked.
[  FAILED  ] OOPBrowserTest.Basic, where TypeParam =  and GetParam() =  (1441 ms)

The most recent Linux ChromeOS failure was:
https://ci.chromium.org/buildbot/chromium.memory/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20(1)/27217

It's stack looks different, so I'm not sure if there are separate causes:
 ERROR:sandbox_linux.cc(378)] InitializeSandbox() called with multiple threads in process gpu-process.
[30901:30901:0427/042809.660941:INFO:GrGLInterface.cpp(460)] ../../third_party/skia/src/gpu/gl/GrGLInterface.cpp:460 GrGLInterface::validate() failed.
[30901:30901:0427/042809.661209:ERROR:gles2_cmd_decoder.cc(3910)] OOP raster support disabled: GrContext creation failed.
[30901:30901:0427/042812.639882:WARNING:gl_context_glx.cc(288)] Could not disable vsync: driver does not support swap control
Received signal 11 SEGV_MAPERR 7f5e1bcc5400
.....bunch of non-symbolized stack....

Followed by:
../../content/browser/oop_browsertest.cc:81: Failure
Value of: snapshot.drawsNothing()
  Actual: true
Expected: false

khushalsagar@ as you re-landed this test, could you help triage this issue?
 
Cc: fsam...@chromium.org wjmaclean@chromium.org

Comment 2 by creis@chromium.org, May 4 2018

Cc: m...@chromium.org
Components: -Internals>Sandbox>SiteIsolation Internals>Compositing>OOP-Raster
OOPBrowserTest does not appear to be a Site Isolation test.  I think it's about OOP Rasterization?
Labels: -Pri-3 Pri-2
Yeah, OOPBrowserTest is for OOP raster. I'll investigate. The test has been there for a while so may be a recent change caused it to become flaky.
Cc: backer@chromium.org
The first failure doesn't indicate anything. Just that our logic for when a snapshot is ready is not perfect, we insert a visual state callback that round trips through the renderer pipeline and expect that a frame should be ready when it finishes. I'm going to replace it with RenderFrameSubmissionObserver which is the standard way to wait for a renderer frame.

The second one indicates that OOP raster is not supported. I suppose which should run run the test when that happens, but there is no way of knowing that in the browser process right now. backer@, did you have a change up through which we can know about GrContext disabling oop-r in the browser?
Cc: khushals...@chromium.org
 Issue 846621  has been merged into this issue.
Re comment #4. Some support just landed today. It should be part of GPUInfo (https://cs.chromium.org/chromium/src/gpu/config/gpu_info.h?rcl=7bff70e203b953d03b41d419fa377d694d1b41d5&l=249). enne@ is about to add it to GpuFeatureInfo as well in http://crrev.com/c/1083115  (see render_thread_impl.cc)

GPUInfo will just state if OOP-R is supported. GpuFeatureInfo will tell you if it's made it past the blacklist. So probably better to wait for that CL.
Project Member

Comment 7 by bugdroid1@chromium.org, Jun 4 2018

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

commit 200a0e399c5c3a51b8e13ade08a3b0b1faddb188
Author: Khushal <khushalsagar@chromium.org>
Date: Mon Jun 04 21:52:09 2018

viz: Defer frame token updates to embedders until surface activation.

Defer notifying of an updated token to the embedders until after
OnFirstSurfaceActivation, to ensure that all side-effects from the
update are finished.

R=fsamuel@chromium.org

Bug:  839861 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I7771d456ec5d3785c8149113c807d318d63861f6
Reviewed-on: https://chromium-review.googlesource.com/1083814
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#564251}
[modify] https://crrev.com/200a0e399c5c3a51b8e13ade08a3b0b1faddb188/components/viz/service/frame_sinks/compositor_frame_sink_support.cc
[modify] https://crrev.com/200a0e399c5c3a51b8e13ade08a3b0b1faddb188/components/viz/service/frame_sinks/compositor_frame_sink_support.h
[modify] https://crrev.com/200a0e399c5c3a51b8e13ade08a3b0b1faddb188/components/viz/service/frame_sinks/compositor_frame_sink_support_unittest.cc
[modify] https://crrev.com/200a0e399c5c3a51b8e13ade08a3b0b1faddb188/components/viz/service/surfaces/surface.cc
[modify] https://crrev.com/200a0e399c5c3a51b8e13ade08a3b0b1faddb188/components/viz/service/surfaces/surface_client.h

Project Member

Comment 8 by bugdroid1@chromium.org, Jun 4 2018

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

commit bc7290e8da72ee3205b702203f9e9d726390bf79
Author: Khushal <khushalsagar@chromium.org>
Date: Mon Jun 04 22:40:36 2018

content: Fix OOPBrowserTest flakiness.

Use RenderFrameSubmissionObserver to wait for renderer frames in the
browser instead of visual state update callbacks.

R=fsamuel@chromium.org

Bug:  839861 
Change-Id: I9464b07c02090c3032fa9d26ec6483e4a34c399b
Reviewed-on: https://chromium-review.googlesource.com/1081186
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#564277}
[modify] https://crrev.com/bc7290e8da72ee3205b702203f9e9d726390bf79/content/browser/oop_browsertest.cc

Status: Fixed (was: Assigned)
Flakiness seems to be fixed. I guess its fine to run the test even if we don't get oop-r, its a super simple integration test that should pass either way.

Sign in to add a comment