Several tests failing on the win/cross bot |
|
Issue descriptionhttps://ci.chromium.org/buildbot/chromium.clang/linux-win_cross-rel/1793 (The bot's been red in generate_build_files for a while due to other reasons, so not clear where this started. There were a bunch of v8-related crashes after that -- issue v8:7837 , now fixed. This bug here is about what's left now that the v8 thing is resolved.) These tests fail: viz_browser_tests -- whole suite times out, probably need to copy swarming settings from regular browser_tests content_browsertests, viz_content_browsertests: NavigationControllerBrowserTest.FrameNavigationEntry_RecreatedSubframeBackForward (times out; not in viz) RenderFrameHostManagerTest.BackForwardNotStale (times out) RenderFrameHostManagerTest.BrowserInitiatedNavigationsSwapBrowsingInstance (times out) TopDocumentIsolationTest.FramesForSitesInHistory (times out) WebUIMojoTest.ChromeSendAvailable (times out) WebUIMojoTest.NativeMojoAvailable (times out) content_unittests: BluetoothBlocklistTest.InvalidUUID (times out) WebBluetoothDeviceIdTest.DefaultConstructor (times out after passing?) headless_browsertests: HeadlessWebContentsPDFTest.RunAsyncTest (times out) interactive_ui_tests: WindowActivityWatcherTest.DontFloodUkm (times out) service_manager_unittests: SandboxWinTest.AppContainerUnsupportedType This one has a stack: [ RUN ] SandboxWinTest.AppContainerUnsupportedType [1716:4344:0609/183307.687:14217593:FATAL:sandbox_win.cc(596)] Check failed: sandbox_type == service_manager::SANDBOX_TYPE_GPU. Backtrace: base::debug::StackTrace::StackTrace [0x00007FFA4EF07BE4+36] logging::LogMessage::~LogMessage [0x00007FFA4EF3506F+95] service_manager::SandboxWin::AddAppContainerProfileToPolicy [0x00007FFA5FBB260A+128] service_manager::SandboxWinTest_AppContainerAccessCheckFail_Test::TestBody [0x00007FF6DA06EBFF+863] service_manager::SandboxWinTest_AppContainerUnsupportedType_Test::TestBody [0x00007FF6DA06FD20+96] testing::Test::Run [0x00007FF6DA099E6D+199] testing::TestInfo::Run [0x00007FF6DA09A7FB+223] testing::TestCase::Run [0x00007FF6DA09AD71+259] testing::internal::UnitTestImpl::RunAllTests [0x00007FF6DA0A208D+641] testing::UnitTest::Run [0x00007FF6DA0A1D18+168] base::TestSuite::Run [0x00007FF6DA0C0892+120] base::OnceCallback<int __cdecl(void)>::Run [0x00007FF6DA0C34E5+55] base::LaunchUnitTests [0x00007FF6DA0C23A6+570] base::LaunchUnitTests [0x00007FF6DA0C222E+194] service_manager::InitializeAndLaunchUnitTests [0x00007FF6DA0BF76A+278] main [0x00007FF6DA07E128+172] __scrt_common_main_seh [0x00007FF6DA1438FC+268] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283) BaseThreadInitThunk [0x00007FFA6DF52774+20] RtlUserThreadStart [0x00007FFA6F070D51+33]
,
Jun 11 2018
Re viz_browser_tests: That's already as sharded as browser_tests itself, so not sure what's up with that.
,
Jun 12 2018
SandboxWinTest fails on other bots too, see issue 852004
,
Jul 25
FWIW we see BluetoothBlocklistTest.InvalidUUID and WebBluetoothDeviceIdTest.DefaultConstructor flake frequently on Fuchsia/ARM64/Rel on FYI. Both tests contain eight death-expectations each, i.e. eight lots of sub-process startup and teardown, which is presumably why they take so long. The pass-but-timeout behaviour happens because TestLauncher enforces a batch-level timeout (i.e. if the sub-process runs ten tests w/ 45s timeout, it gets 450s to run), and the TestLauncher post-processes the results of passed runs to retrospectively mark tests that exceeded the single-test timeout as "TIMED OUT". |
|
►
Sign in to add a comment |
|
Comment 1 by thakis@chromium.org
, Jun 11 2018Status: Assigned (was: Unconfirmed)