"MojoDOMStorageBrowserTest.DataPersists" is flaky |
|||
Issue description"MojoDOMStorageBrowserTest.DataPersists" is flaky. This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label. We have detected 3 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyMQsSBUZsYWtlIiZNb2pvRE9NU3RvcmFnZUJyb3dzZXJUZXN0LkRhdGFQZXJzaXN0cww. Flaky tests should be disabled within 30 minutes unless culprit CL is found and reverted. Please see more details here: https://sites.google.com/a/chromium.org/dev/developers/tree-sheriffs/sheriffing-bug-queues#triaging-auto-filed-flakiness-bugs
,
Feb 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e8793e385f6bf50a48f5a5798af67e5c518ea8a4 commit e8793e385f6bf50a48f5a5798af67e5c518ea8a4 Author: mgiuca <mgiuca@chromium.org> Date: Thu Feb 16 08:13:31 2017 Disabled MojoDOMStorageBrowserTest.DataPersists on Windows (flake). BUG= 692885 TBR=mek@chromium.org Review-Url: https://codereview.chromium.org/2688413013 Cr-Commit-Position: refs/heads/master@{#450895} [modify] https://crrev.com/e8793e385f6bf50a48f5a5798af67e5c518ea8a4/content/browser/dom_storage/dom_storage_browsertest.cc
,
Feb 16 2017
Hmm, seems the test worked mostly fine before https://codereview.chromium.org/2697953002 and then suddenly became a lot more flaky, but only on this one bot... weird. I'll see if I can figure out what's going on/how to deflake the test.
,
Feb 16 2017
This might be a related issue: I saw the following DCHECK failure when trying my CL: Bot: https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_asan_rel_ng/builds/312556 CL: https://codereview.chromium.org/2695333002/ (I think the CL itself should be irrelevant to the issue). This DCHECK failure is that a callback for Put is not run before we destroy it. Because in this case we will destroy the Binding object (which disconnects the message pipe) soon so it isn't really a bug. You could avoid this DCHECK by changing the destruction order so that the Binding is destructed first. However, it indicates that some write operation is not done as expected? Another thing that may worth mentioning: I landed a CL to simplify the associated interface API two days ago (https://codereview.chromium.org/2646853003/). I am not sure whether it has anything to do with the flaky test. Maybe it changes timing of some tasks and reveals the race? (Or maybe my CL is buggy itself?) Feel free to ping me if you need more details. ========================================================================================================================== MojoDOMStorageBrowserTest.PRE_DataPersists (run #1): [ RUN ] MojoDOMStorageBrowserTest.PRE_DataPersists [10453:10453:0216/100612.994809:7267971581:WARNING:audio_manager.cc(322)] Multiple instances of AudioManager detected [10453:10453:0216/100612.995010:7267971715:WARNING:audio_manager.cc(279)] Multiple instances of AudioManager detected Xlib: extension "RANDR" missing on display ":99". ----------------------------------------------------- Suppressions used: count bytes template 2 288 libfontconfig ----------------------------------------------------- [10453:10453:0216/100615.177851:7270154563:FATAL:interface_endpoint_client.cc(32)] Check failed: !is_valid. The callback passed to LevelDBWrapper::Put() was never run. #0 0x00000052feb1 __interceptor_backtrace #1 0x000006c685cc base::debug::StackTrace::StackTrace() #2 0x000006cb8072 logging::LogMessage::~LogMessage() #3 0x000006232a24 mojo::(anonymous namespace)::DCheckIfInvalid() #4 0x000006231fcb mojo::(anonymous namespace)::ResponderThunk::DCheckInvalid() #5 0x000001664662 _ZN4base8internal9BindStateIMN7content5mojom35LevelDBWrapper_Put_ProxyToResponderEFvbEJNS0_13PassedWrapperINSt3__110unique_ptrIS4_NS8_14default_deleteIS4_EEEEEEEE7DestroyEPKNS0_13BindStateBaseE #6 0x000004eaa9be _ZN4base8internal9BindStateIMN7content18LevelDBWrapperImplEFvRKNSt3__16vectorIhNS4_9allocatorIhEEEESA_RKNS4_12basic_stringIcNS4_11char_traitsIcEENS6_IcEEEERKNS_8CallbackIFvbELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEJNS0_17UnretainedWrapperIS3_EES8_S8_SF_SM_EE7DestroyEPKNS0_13BindStateBaseE #7 0x000004e983c1 content::LevelDBWrapperImpl::~LevelDBWrapperImpl() #8 0x000004e9af0e content::LevelDBWrapperImpl::~LevelDBWrapperImpl() #9 0x0000049ec5ca std::__1::__tree<>::destroy() #10 0x0000049e2f8c content::LocalStorageContextMojo::~LocalStorageContextMojo() #11 0x0000049c7623 content::DOMStorageContextWrapper::Shutdown() #12 0x00000561f221 content::StoragePartitionImpl::~StoragePartitionImpl() #13 0x00000561fe0e content::StoragePartitionImpl::~StoragePartitionImpl() #14 0x000005634d76 std::__1::__tree<>::destroy() #15 0x00000562fd65 content::StoragePartitionImplMap::~StoragePartitionImplMap() #16 0x000006d95a3d std::__1::__tree<>::__erase_unique<>() #17 0x000006d95226 base::SupportsUserData::RemoveUserData() #18 0x000005fd41a8 content::ShellBrowserContext::~ShellBrowserContext() #19 0x000005fd458e content::ShellBrowserContext::~ShellBrowserContext() #20 0x000005fd6ac2 content::ShellBrowserMainParts::PostMainMessageLoopRun() #21 0x0000047ab60f content::BrowserMainLoop::ShutdownThreadsAndCleanUp() #22 0x0000047b7eb6 content::BrowserMainRunnerImpl::Shutdown() #23 0x000005f6e269 ShellBrowserMain() #24 0x000005f511cf content::ShellMainDelegate::RunProcess() #25 0x0000044d59c7 content::RunNamedProcessTypeMain() #26 0x0000044d752c content::ContentMainRunnerImpl::Run() #27 0x00000217ee6b content::ContentMain() #28 0x000005e33441 content::BrowserTestBase::SetUp() #29 0x000005e12c32 content::ContentBrowserTest::SetUp() #30 0x00000652239d testing::Test::Run() #31 0x000006523e45 testing::TestInfo::Run() #32 0x000006524f47 testing::TestCase::Run() #33 0x00000653a537 testing::internal::UnitTestImpl::RunAllTests() #34 0x000006539a78 testing::UnitTest::Run() #35 0x000005ed3c87 base::TestSuite::Run() #36 0x000005e200a0 content::ContentTestLauncherDelegate::RunTestSuite() #37 0x000005e818a2 content::LaunchTests() #38 0x000005e1ff27 main #39 0x7f6ce47fff45 __libc_start_main #40 0x0000004e4779 <unknown>
,
Feb 21 2017
Also flaky on Linux: MojoDOMStorageBrowserTest.
,
Feb 21 2017
Issue 693844 has been merged into this issue.
,
Feb 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b57016555f22c0e162f449567d58e9a3a00b146f commit b57016555f22c0e162f449567d58e9a3a00b146f Author: fdoray <fdoray@chromium.org> Date: Tue Feb 21 22:38:18 2017 Disable MojoDOMStorageBrowserTest.DataPersists on Linux. BUG= 692885 TBR=mek@chromium.org Review-Url: https://codereview.chromium.org/2710583004 Cr-Commit-Position: refs/heads/master@{#451853} [modify] https://crrev.com/b57016555f22c0e162f449567d58e9a3a00b146f/content/browser/dom_storage/dom_storage_browsertest.cc
,
Feb 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8a7d571a3c9fbe2bac5d02a79848d2c188a264c0 commit 8a7d571a3c9fbe2bac5d02a79848d2c188a264c0 Author: mek <mek@chromium.org> Date: Tue Feb 28 23:43:30 2017 Fix flaky MojoDOMStorageBrowserTest Rather than waiting for a connection to the database after the first part of the test runs, make sure we're connected before starting the test. This should make sure that all changes are actually flushed before the browser shuts down. BUG= 692885 Review-Url: https://codereview.chromium.org/2700003002 Cr-Commit-Position: refs/heads/master@{#453745} [modify] https://crrev.com/8a7d571a3c9fbe2bac5d02a79848d2c188a264c0/content/browser/dom_storage/dom_storage_browsertest.cc
,
Mar 15 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by mgiuca@chromium.org
, Feb 16 2017Labels: -Sheriff-Chromium
Owner: mek@chromium.org
Status: Assigned (was: Untriaged)