SyncAwareCounterTest.AutofillCounter browser_test failed with FATAL:affiliation_database.cc(343): database is locked |
||||||||
Issue descriptionhttps://ci.chromium.org/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/45945 https://logs.chromium.org/v/?s=chromium%2Fbb%2Ftryserver.chromium.win%2Fwin7_chromium_rel_ng%2F45945%2F%2B%2Frecipes%2Fsteps%2Fbrowser_tests__with_patch_%2F0%2Flogs%2FSyncAwareCounterTest.AutofillCounter%2F0 Log excerpt: [5116:5712:1116/133426.977:FATAL:affiliation_database.cc(343)] database is locked Backtrace: base::debug::StackTrace::StackTrace [0x0348C2D0+32] base::debug::StackTrace::StackTrace [0x0344CB8D+13] logging::LogMessage::~LogMessage [0x033F6F5E+78] password_manager::AffiliationDatabase::SQLErrorCallback [0x06A5D0C2+130] base::internal::Invoker<base::internal::BindState<void (__thiscall OneGoogleBarService::*)(enum OneGoogleBarFetcher::Status,base::Optional<OneGoogleBarData> const &),base::internal::UnretainedWrapper<OneGoogleBarService> >,void __cdecl(enum OneGoogleBarFe [0x06226792+18] base::RepeatingCallback<void __cdecl(unsigned __int64)>::Run [0x04AC9FC7+51] sql::Connection::OnSqliteError [0x0451CBA8+618] sql::Connection::OpenInternal [0x04519C51+1149] sql::Connection::Open [0x045197B5+327] password_manager::AffiliationDatabase::Init [0x06A5CDF0+222] password_manager::AffiliationBackend::Initialize [0x06A583CD+221] base::internal::Invoker<base::internal::BindState<bool (__thiscall PolicyToolUIHandler::*)(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &),base::internal::UnretainedWrapper<PolicyToolUIHandler>,std::basic_string<char,std::cha [0x0254C923+19] base::debug::TaskAnnotator::RunTask [0x03489425+229] base::internal::TaskTracker::RunOrSkipTask [0x034A1633+659] base::internal::TaskTracker::RunNextTask [0x034A0C4B+299] base::internal::SchedulerWorker::Thread::ThreadMain [0x034C9683+611] base::PlatformThread::GetCurrentThreadPriority [0x03419F73+467] BaseThreadInitThunk [0x759F337A+18] I'm not sure how often this is flaking on the win7_chromium_rel_ng tryserver. It's nearly impossible to see given the redness from Issue 784182 . Please triage urgently. Thanks.
,
Nov 17 2017
This hasn't failed on the last 200+ runs of win7_chromium_rel_ng (from 46336 to 46546). Removing Sheriff-Chromium label since it looks like no action from sheriffs is necessary at this time. Please re-add the label new flakes are found.
,
Nov 22 2017
Linux too: https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/593387 All I did in my CL is add comments: https://chromium-review.googlesource.com/c/chromium/src/+/784313 testing/buildbot/filters/mojo.fyi.mash.browser_tests.filter also complains about this test not working.
,
Nov 22 2017
,
Nov 22 2017
It looks like the AffiliationDatabase is enabled based on sync service changes. I guess the frequent sequence of enabling and disabling sync in this test is an issue but if that is the case, it should happen on the other tests as well, especially SyncAwareCounterTest.PasswordCounter. https://cs.chromium.org/chromium/src/components/password_manager/core/browser/password_store_factory_util.cc?l=73&rcl=bf8aaf87a2716c2596ab71b48d6e278629871087. I don't see any test failures for SyncAwareCounterTest on the dashboard: https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=SyncAwareCounterTest. I noticed that HistoryCounter has a few timeouts and I have an idea what that could be.
,
Nov 23 2017
Yeah nothing shows up here either in the past month: https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyLwsSBUZsYWtlIiRTeW5jQXdhcmVDb3VudGVyVGVzdC5BdXRvZmlsbENvdW50ZXIM Not sure why thestig@'s failure doesn't show up in the dashboard. I could disable the test but it seems like the failures are very rare and not showing up on the dashboards. It's unlikely that it would be actionable so I am just going to WontFix this. [Investigating this takes a very long time and every sheriff is going to go through this until someone takes action.] Feel free to re-open if it starts showing up on dashboards or fails more reliably.
,
Nov 23 2017
Rather than close this bug, since dullweber@ indicates he has an idea about a potentially related timeout, let's leave it open and remove the Sheriff-Chromium label.
,
Nov 28 2017
I created a CL to improve the WaitForDeletion() calls but I don't think that actually fixes the HistorySyncTest timeouts. (https://crrev.com/c/785370) This is independent of the database locking issue in this bug.
,
Nov 30 2017
Issue 789946 has been merged into this issue.
,
Nov 30 2017
engedy@, jdoerrie: Do you have an idea what is happening in affiliation_database.cc or should I disable the test for now?
,
Nov 30 2017
Hah, each subsequent instance of the AffiliationDatabase uses a new SequencedTaskRunners for I/O (see [1]), so there is a race between DB instance_i closing on its own I/O task runner, and DB instance_(i+1) opening on another one. This sounds a bit ridiculous, but the solution seems to be using the same task runner for all instances, I'll prepare a CL to this effect tomorrow once I'm back in the office. [1]: https://cs.chromium.org/chromium/src/components/password_manager/core/browser/password_store_factory_util.cc?rcl=a8cff8d55cc2649401f26678258adf82d220ff23&l=42
,
Dec 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/944339838e32dc855fa228caadc7b05f143f4eb3 commit 944339838e32dc855fa228caadc7b05f143f4eb3 Author: Balazs Engedy <engedy@chromium.org> Date: Fri Dec 01 18:47:54 2017 Run subsequent AffiliationBackends on the same sequence. This ensures that in browser tests where the sync state is toggled off and on in quick succession, the first AffiliationBackend instance will have always closed the affiliation database before the second instance tries to open it again. Bug: 786157 Change-Id: I9dc724fc198c95de15ae6d877a298695162d80c3 Reviewed-on: https://chromium-review.googlesource.com/803494 Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org> Commit-Queue: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#520998} [modify] https://crrev.com/944339838e32dc855fa228caadc7b05f143f4eb3/components/password_manager/core/browser/password_store_factory_util.cc
,
Dec 1 2017
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kbr@chromium.org
, Nov 16 2017