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

Issue 843998 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocking:
issue 892076



Sign in to add a comment

DCHECK in UserEventSyncBridge with --enable-local-sync-backend

Project Member Reported by treib@chromium.org, May 17 2018

Issue description

Repro: Start Chrome with --enable-local-sync-backend, watch it crash on startup.
Only tested on Windows since local Sync is only enabled on Windows AFAIK; not sure if it'll reproduce on other OSes.

$ out/Release/chrome --enable-logging=stdout --user-data-dir=C:/asdf1 --enable-local-sync-backend
[10392:24224:0517/152615.470:FATAL:user_event_sync_bridge.cc(159)] Check failed: !GetAuthenticatedAccountId().empty().
Backtrace:
        base::debug::StackTrace::StackTrace [0x00007FF86259F554+36] (C:\src\chromium\src\base\debug\stack_trace_win.cc:286)
        logging::LogMessage::~LogMessage [0x00007FF8625D4AAF+95] (C:\src\chromium\src\base\logging.cc:593)
        syncer::UserEventSyncBridge::OnSyncStarting [0x00007FF845BFDD5B+167] (C:\src\chromium\src\components\sync\user_events\user_event_sync_bridge.cc:159)
        syncer::ClientTagBasedModelTypeProcessor::OnSyncStarting [0x00007FF845BE60B1+473] (C:\src\chromium\src\components\sync\model_impl\client_tag_based_model_type_processor.cc:85)
        syncer::`anonymous namespace'::OnSyncStartingHelperOnModelThread [0x00007FF84645820A+78] (C:\src\chromium\src\components\sync\driver\model_type_controller.cc:34)
        base::internal::FunctorTraits<void (*)(const base::RepeatingCallback<void (const syncer::ModelError &)> &, base::OnceCallback<void (std::unique_ptr<syncer::ActivationContext,std::default_delete<syncer::ActivationContext> >)>, base::WeakPtr<syncer::ModelTy [0x00007FF84645B4BA+92] (C:\src\chromium\src\base\bind_internal.h:402)
        base::OnceCallback<void (base::WeakPtr<syncer::ModelTypeControllerDelegate>)>::Run [0x00007FF84645A7DF+61] (C:\src\chromium\src\base\callback.h:97)
        syncer::`anonymous namespace'::RunModelTask [0x00007FF84645A395+105] (C:\src\chromium\src\components\sync\driver\model_type_controller.cc:82)
        base::internal::Invoker<base::internal::BindState<void (*)(base::OnceCallback<base::WeakPtr<syncer::ModelTypeControllerDelegate> ()>, base::OnceCallback<void (base::WeakPtr<syncer::ModelTypeControllerDelegate>)>),base::OnceCallback<base::WeakPtr<syncer::M [0x00007FF84645C2FC+74] (C:\src\chromium\src\base\bind_internal.h:589)
        base::debug::TaskAnnotator::RunTask [0x00007FF8625A133E+382] (C:\src\chromium\src\base\debug\task_annotator.cc:101)
        base::internal::IncomingTaskQueue::RunTask [0x00007FF8625EF23E+126] (C:\src\chromium\src\base\message_loop\incoming_task_queue.cc:124)
        base::MessageLoop::RunTask [0x00007FF8625F45E9+665] (C:\src\chromium\src\base\message_loop\message_loop.cc:320)
        base::MessageLoop::DeferOrRunPendingTask [0x00007FF8625F4F27+183] (C:\src\chromium\src\base\message_loop\message_loop.cc:329)
        base::MessageLoop::DoWork [0x00007FF8625F51CE+542] (C:\src\chromium\src\base\message_loop\message_loop.cc:373)
        base::MessagePumpForUI::DoRunLoop [0x00007FF8625F9C49+169] (C:\src\chromium\src\base\message_loop\message_pump_win.cc:174)
        base::MessagePumpWin::Run [0x00007FF8625F9408+104] (C:\src\chromium\src\base\message_loop\message_pump_win.cc:58)
        base::MessageLoop::Run [0x00007FF8625F3EDB+139] (C:\src\chromium\src\base\message_loop\message_loop.cc:273)
        base::RunLoop::Run [0x00007FF862653BB9+249] (C:\src\chromium\src\base\run_loop.cc:134)
        ChromeBrowserMainParts::MainMessageLoopRun [0x00007FF8441099C4+240] (C:\src\chromium\src\chrome\browser\chrome_browser_main.cc:2138)
        content::BrowserMainLoop::RunMainMessageLoopParts [0x00007FF840C0070E+72] (C:\src\chromium\src\content\browser\browser_main_loop.cc:972)
        content::BrowserMainRunnerImpl::Run [0x00007FF840C04C09+169] (C:\src\chromium\src\content\browser\browser_main_runner_impl.cc:161)
        content::BrowserMain [0x00007FF840BFB717+203] (C:\src\chromium\src\content\browser\browser_main.cc:46)
        content::ContentMainRunnerImpl::Run [0x00007FF841A79BBF+425] (C:\src\chromium\src\content\app\content_main_runner_impl.cc:946)
        service_manager::Main [0x00007FF837BDC3AC+1183] (C:\src\chromium\src\services\service_manager\embedder\main.cc:452)
        content::ContentMain [0x00007FF841A791AB+67] (C:\src\chromium\src\content\app\content_main.cc:19)
        ChromeMain [0x00007FF84335C030+332] (C:\src\chromium\src\chrome\app\chrome_main.cc:104)
        MainDllLoader::Launch [0x00007FF685FEDAD1+627] (C:\src\chromium\src\chrome\app\main_dll_loader_win.cc:201)
        wWinMain [0x00007FF685FEADBB+2223] (C:\src\chromium\src\chrome\app\chrome_exe_main_win.cc:230)
        __scrt_common_main_seh [0x00007FF6860E6573+279] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
        BaseThreadInitThunk [0x00007FF88C921FE4+20]
        RtlUserThreadStart [0x00007FF88F11F061+33]
 

Comment 1 by mastiz@chromium.org, May 17 2018

I guess the question is, why are user events even enabled in local sync?

Comment 2 by treib@chromium.org, May 17 2018

Well, because there's nothing that would disable them - AFAIK local sync uses the same set of default data types as actual sync. So either we need some more special casing for local sync, or user events need to check the auth state separately from the sync state.

Comment 3 by treib@chromium.org, Jun 7 2018

Cc: -vitaliii@chromium.org pastarmovj@chromium.org
Owner: vitaliii@chromium.org
Assigning to vitaliii for user_events, since I think the DCHECK in UserEventSyncBridge just isn't valid in the "local Sync" case. We either need to *not* create the bridge when in local Sync mode, or it needs to handle this case.

From looking over the code, I don't think this will cause actual problems in release builds, but we should still fix it ASAP. Failing DCHECKs are Bad.
FYI, I may not have time to address this until 25th of June.
If anyone needs this sooner, please reassign.
Blocking: 851433

Comment 6 by mastiz@chromium.org, Jun 20 2018

Triage ping: should we adjust as P2? P1 are supposed to have an owner that is actively working on the issue.
Labels: -Pri-1 Pri-2

Comment 8 by mastiz@chromium.org, Jun 27 2018

Looks like this is fixed by now.
Do you mean the DCHECK failure or not enabling user events/consents under --enable-local-sync-backend?
I meant the DCHECK. Can we mark this as fixed?

If not, does it qualify for a fixit?
So DCHECK seems to be fixed.
But the idea was to disable consent/events completely in local mode.
I am not familiar with local sync, but this feels too undefined for the fixit for me.
I don't think disabling consents/events in local Sync mode is too undefined for the fixit. Basically there's SyncService::IsLocalSyncEnabled, which is guaranteed not to change at runtime. So you'd just have to check that somewhere during initialization, and if it's true, turn off the corresponding data types.
Cool, then it sounds perfect for the fixit :)
triage ping
sync-triage-ping, any updates?
Blocking: 892076
Blocking: -851433
Owner: ----
Status: Available (was: Assigned)
We should not enable user events and consents if SyncService::IsLocalSyncEnabled.
Status: WontFix (was: Available)

Sign in to add a comment