Crash when re-enabling cards autofill toggle |
|||||
Issue descriptionJust ran in to this while testing on HEAD (after crrev.com/1290149). I had full sync enabled, and I turned on the "Save and fill payment methods" toggle. Crash: [96614:96723:1023/130955.597474:FATAL:model_type_worker.cc(354)] Check failed: model_type_state_.initial_sync_done(). #0 0x7f56c05d9d4d base::debug::StackTrace::StackTrace() #1 0x7f56c02d6a2a base::debug::StackTrace::StackTrace() #2 0x7f56c034861b logging::LogMessage::~LogMessage() #3 0x561057c8f283 syncer::ModelTypeWorker::ApplyUpdates() #4 0x561057ccebbf syncer::(anonymous namespace)::NonPassiveApplyUpdates() #5 0x561057cce949 syncer::NormalGetUpdatesDelegate::ApplyUpdates() #6 0x561057cccb3d syncer::GetUpdatesProcessor::ApplyUpdates() #7 0x561057cc5596 syncer::Syncer::DownloadAndApplyUpdates() #8 0x561057cc5189 syncer::Syncer::NormalSyncShare() #9 0x561057c69c11 syncer::SyncSchedulerImpl::DoNudgeSyncCycleJob() #10 0x561057c6d203 syncer::SyncSchedulerImpl::TrySyncCycleJobImpl() #11 0x561051e9aa0f _ZN4base8internal13FunctorTraitsIMN4gaia15GaiaOAuthClient4CoreEFvvEvE6InvokeIS6_NS_7WeakPtrIS4_EEJEEEvT_OT0_DpOT1_ #12 0x561051e9a98a _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIMN4gaia15GaiaOAuthClient4CoreEFvvENS_7WeakPtrIS6_EEJEEEvOT_OT0_DpOT1_ #13 0x561051e9a920 _ZN4base8internal7InvokerINS0_9BindStateIMN4gaia15GaiaOAuthClient4CoreEFvvEJNS_7WeakPtrIS5_EEEEEFvvEE7RunImplIS7_NSt3__15tupleIJS9_EEEJLm0EEEEvOT_OT0_NSE_16integer_sequenceImJXspT1_EEEE #14 0x561051e9a869 _ZN4base8internal7InvokerINS0_9BindStateIMN4gaia15GaiaOAuthClient4CoreEFvvEJNS_7WeakPtrIS5_EEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE #15 0x7f56c02863ee _ZNO4base12OnceCallbackIFvvEE3RunEv #16 0x7f56c02d8072 base::debug::TaskAnnotator::RunTask() #17 0x7f56c036d4e6 base::MessageLoop::RunTask() #18 0x7f56c036d86e base::MessageLoop::DeferOrRunPendingTask() #19 0x7f56c036dcf9 base::MessageLoop::DoWork() #20 0x7f56c03746f7 base::MessagePumpDefault::Run() #21 0x7f56c036cbdb base::MessageLoop::Run() #22 0x7f56c041912d base::RunLoop::Run() #23 0x7f56c05155c8 base::Thread::Run() #24 0x7f56c051628e base::Thread::ThreadMain() #25 0x7f56c06140bd base::(anonymous namespace)::ThreadFunc() #26 0x7f569676a494 start_thread #27 0x7f56925c6a8f clone Received signal 6 #0 0x7f56c05d9d4d base::debug::StackTrace::StackTrace() #1 0x7f56c02d6a2a base::debug::StackTrace::StackTrace() #2 0x7f56c05d979a base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7f56967740c0 <unknown> #4 0x7f5692510fcf gsignal #5 0x7f56925123fa abort #6 0x7f56c05d8f46 base::debug::(anonymous namespace)::DebugBreak() #7 0x7f56c05d8f28 base::debug::BreakDebugger() #8 0x7f56c0349431 logging::LogMessage::~LogMessage() #9 0x561057c8f283 syncer::ModelTypeWorker::ApplyUpdates() #10 0x561057ccebbf syncer::(anonymous namespace)::NonPassiveApplyUpdates() #11 0x561057cce949 syncer::NormalGetUpdatesDelegate::ApplyUpdates() #12 0x561057cccb3d syncer::GetUpdatesProcessor::ApplyUpdates() #13 0x561057cc5596 syncer::Syncer::DownloadAndApplyUpdates() #14 0x561057cc5189 syncer::Syncer::NormalSyncShare() #15 0x561057c69c11 syncer::SyncSchedulerImpl::DoNudgeSyncCycleJob() #16 0x561057c6d203 syncer::SyncSchedulerImpl::TrySyncCycleJobImpl() #17 0x561051e9aa0f _ZN4base8internal13FunctorTraitsIMN4gaia15GaiaOAuthClient4CoreEFvvEvE6InvokeIS6_NS_7WeakPtrIS4_EEJEEEvT_OT0_DpOT1_ #18 0x561051e9a98a _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIMN4gaia15GaiaOAuthClient4CoreEFvvENS_7WeakPtrIS6_EEJEEEvOT_OT0_DpOT1_ #19 0x561051e9a920 _ZN4base8internal7InvokerINS0_9BindStateIMN4gaia15GaiaOAuthClient4CoreEFvvEJNS_7WeakPtrIS5_EEEEEFvvEE7RunImplIS7_NSt3__15tupleIJS9_EEEJLm0EEEEvOT_OT0_NSE_16integer_sequenceImJXspT1_EEEE #20 0x561051e9a869 _ZN4base8internal7InvokerINS0_9BindStateIMN4gaia15GaiaOAuthClient4CoreEFvvEJNS_7WeakPtrIS5_EEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE #21 0x7f56c02863ee _ZNO4base12OnceCallbackIFvvEE3RunEv #22 0x7f56c02d8072 base::debug::TaskAnnotator::RunTask() #23 0x7f56c036d4e6 base::MessageLoop::RunTask() #24 0x7f56c036d86e base::MessageLoop::DeferOrRunPendingTask() #25 0x7f56c036dcf9 base::MessageLoop::DoWork() #26 0x7f56c03746f7 base::MessagePumpDefault::Run() #27 0x7f56c036cbdb base::MessageLoop::Run() #28 0x7f56c041912d base::RunLoop::Run() #29 0x7f56c05155c8 base::Thread::Run() #30 0x7f56c051628e base::Thread::ThreadMain() #31 0x7f56c06140bd base::(anonymous namespace)::ThreadFunc() #32 0x7f569676a494 start_thread #33 0x7f56925c6a8f clone r8: 0000000000000000 r9: 00007f566b98f000 r10: 0000000000000008 r11: 0000000000000246 r12: 0000000000000000 r13: 00007ffc4e8a4e2f r14: 0000000000000000 r15: 00007f56c08ed040 di: 0000000000000002 si: 00007f566b98f000 bp: 00007f566b98f240 bx: 0000000000000006 dx: 0000000000000000 ax: 0000000000000000 cx: 00007f5692510fcf sp: 00007f566b98f078 ip: 00007f5692510fcf efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] Calling _exit(1). Core file will not be generated.
,
Oct 23
,
Oct 24
(cc'ing Mikel for any insights into how SyncScheduler works...) Looking forwards (what would happen after the DCHECK): - I see no reason why it should crash when DCHECKs are disabled. - It leaves the model in a weird state as it thinks initial sync has not been done yet: it ignores local updates, etc. - The question is whether this is just a race condition and the model would get into a consistent state or if there is something more fundamental. Looking backwards (to understand why this happens): - the problem arrives at the latest in SyncSchedulerImpl::TrySyncCycleJobImpl() [1] - it should call DoConfigurationSyncCycleJob() but it calls DoNudgeSyncCycleJob(), instead. - I have no clue why it is not in CONFIGURATION_MODE, sometimes. What seems likely is that it is caused by the new implementation of disabling/re-enabling in the USS controller [2] that is different from the previous Directory implementation [3]. The new implementation actually stops the datatype (which allows cleanly deleting the sync data & metadata) whereas the old implementation only pretended an error. It could have been caused by the discrepancy of state of wallet data & wallet metadata (already fixed on trunk). but this theory is getting a bit wild. [1] https://cs.chromium.org/chromium/src/components/sync/engine_impl/sync_scheduler_impl.cc?l=742 [2] https://cs.chromium.org/chromium/src/components/autofill/core/browser/autofill_wallet_model_type_controller.cc?l=52 [3] https://cs.chromium.org/chromium/src/components/autofill/core/browser/autofill_wallet_data_type_controller.cc?l=109
,
Oct 24
Next week, I'll some more debug info to the DCHECKs in ModelTypeWorker (notably type_) so that we get more insight if we ever see it DCHECK again.
,
Oct 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bba2cbfc32be7d441a143d5c0c6b1ab28079fda8 commit bba2cbfc32be7d441a143d5c0c6b1ab28079fda8 Author: Jan Krcal <jkrcal@chromium.org> Date: Tue Oct 30 10:22:21 2018 [Wallet sync] Log more info for DCHECK failures This CL annotates two DCHECKs in ModelTypeWorker with more info. Bug: 898130 Change-Id: I0b1d6159552d7566a86b698e460213f72fb1a126 Reviewed-on: https://chromium-review.googlesource.com/c/1305513 Reviewed-by: Florian Uunk <feuunk@chromium.org> Commit-Queue: Jan Krcal <jkrcal@chromium.org> Cr-Commit-Position: refs/heads/master@{#603853} [modify] https://crrev.com/bba2cbfc32be7d441a143d5c0c6b1ab28079fda8/components/sync/engine_impl/model_type_worker.cc
,
Nov 12
Triage ping for jkrcal@, thanks! I'll be happy to take a look as well.
,
Nov 12
We've never been able to repro the crash again. I've checked Crash, there's no single crash at this LoC so far. I am not sure how to proceed to make efficient use of my time. We can chat offline.
,
Nov 14
I agree. I've been trying to repro this off-and-on for multiple days, but haven't managed since. Given that there are no reports of this on Crash, maybe we should leave this until we get more signals?
,
Nov 14
I agree, setting next action in two weeks from now.
,
Nov 28
The NextAction date has arrived: 2018-11-28
,
Nov 28
Still no crashes out in the wild. Closing as WontFix. Let's re-open it if ever we encounter the crash.
,
Nov 28
Thanks, SGTM. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by feuunk@google.com
, Oct 23