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

Issue 692885 link

Starred by 1 user

Issue metadata

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

Blocking:
issue 586194



Sign in to add a comment

"MojoDOMStorageBrowserTest.DataPersists" is flaky

Project Member Reported by chromium...@appspot.gserviceaccount.com, Feb 16 2017

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
 

Comment 1 by mgiuca@chromium.org, Feb 16 2017

Cc: mgiuca@chromium.org
Labels: -Sheriff-Chromium
Owner: mek@chromium.org
Status: Assigned (was: Untriaged)
This test is new in the past week (https://codereview.chromium.org/2649963002).

The test is:

IN_PROC_BROWSER_TEST_F(MojoDOMStorageBrowserTest, PRE_DataPersists) {
  SimpleTest(GetTestUrl("dom_storage", "store_data.html"), kNotIncognito);
  Flush();
}

IN_PROC_BROWSER_TEST_F(MojoDOMStorageBrowserTest, DataPersists) {
  SimpleTest(GetTestUrl("dom_storage", "verify_data.html"), kNotIncognito);
}

store_data writes and verify_data reads. Are we sure that SimpleTest is going to fully complete (and write the data out) before the verify_data step is run? I suppose that's what Flush is for.

Disabling on Windows due to the above flakes: https://codereview.chromium.org/2688413013
Project Member

Comment 2 by bugdroid1@chromium.org, 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

Comment 3 by mek@chromium.org, Feb 16 2017

Blocking: 586194
Labels: -Pri-1 Pri-2
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. 

Comment 4 by yzshen@chromium.org, 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>

Comment 5 by fdoray@chromium.org, Feb 21 2017

Also flaky on Linux: MojoDOMStorageBrowserTest.

Comment 6 by fdoray@chromium.org, Feb 21 2017

 Issue 693844  has been merged into this issue.
Project Member

Comment 7 by bugdroid1@chromium.org, 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

Project Member

Comment 8 by bugdroid1@chromium.org, 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

Comment 9 by mek@chromium.org, Mar 15 2017

Status: Fixed (was: Assigned)

Sign in to add a comment