OOPBrowserTest.Basic Flaky on ASAN Bots |
|||||
Issue descriptionI'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?
,
May 4 2018
OOPBrowserTest does not appear to be a Site Isolation test. I think it's about OOP Rasterization?
,
May 4 2018
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.
,
May 31 2018
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?
,
May 31 2018
,
Jun 4 2018
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.
,
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
,
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
,
Jun 7 2018
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 |
|||||
Comment 1 by lukasza@chromium.org
, May 4 2018