Tested the issue using #59.0.3071.115 on Win 10 and was able to see the existing bookmarks, settings and extensions after siging in as per the steps mentioned below.

1. Logged into Google account.
2. Noticed that the bookmarks, extensions and settings are synced.

@sander: Could you please find the attached screen cast and let us know your observations.

Thanks!!

Deleted: Jul 14 2017 4-36 AM.webm 5.6 MB

	Jul 14 2017 4-36 AM.webm 5.6 MB View Download

+msarda for the crash described below. Do you know why this could be happening?

I also did some investigation work here and can confirm that signing in after having local sync enabled seems to work as expected. The sync subsystem simply ignores the account data as it uses its local backend which does not try to talk to the server.

I however observed an issue when the profile was syncing against the Google Sync server and then the local sync backend was enabled. This leads to a crash for me in ProfileSyncService::OnActionableError when trying to call SigninManager::SignOut because the wrapper returns bogus pointer in the GetOriginal call. 

+skym: I think what we need in both directions though is to ensure that the SyncState is cleared when the backends are swapped. Not sure if we need to sign out the user but at least the sync client state needs to start as if it is a clear sync attempt. WDYT?

re Comment 2. Sandeep, I do not see that you enabled the local sync backend.
My obervations are the same as in Comment 3.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is "SigninManagerWrapper" the wrapper that returns a bogus SigninManager? I think the SigninManagerWrapper is a class internal to sync, but it looks like a simple warpper, so the crash could come from it not being initialized.

Looking at https://cs.chromium.org/chromium/src/chrome/browser/sync/profile_sync_service_factory.cc?rcl=0a99285795ade2dd281995dee72fdb9e80d3fd6d&l=231 , it looks like the wrapper is not initialized at all when local_sync_backend_enabled is false. Would this explain the crash?

Yeah right :) I should have checked that but I assumed wrongly this have changed with the recent DICE work. I will see how to make this part of the code more robust.

Btw reading the initial report once more it seems to me the original request was if local sync and cloud sync could work at the same time. This is unfortunately not possible in the moment and not a goal of the current design either. Fixing the crashes discovered though is very much a goal still.

Friendly ping, is there a status update here?

Ping again!
What exactly needs to be done here? From reading the thread, it sounds like the problem can be summarized as:
If regular Sync was running in a profile, and then Chrome is restarted with --enable-local-sync-backend, it crashes. Is that accurate?

Actually re-reading the initial request this sounds more like a feature request that the regular sync should be able to import data even when local sync is on. I don't think we want to enable this as if the user is fine to use proper Google Sync it is a strict superset of local sync and thus local sync should not be needed.

If the admin on the other hand has opted to use local sync than most probably this is their wish and Google Sync is not preferred so it again should not be allowed.

The reason however this bug is open because when testing we found that enabling local sync when the user has been using Google Sync was causing a crash. I will close this bug as won't fix and start a clean one describing the issue there to make it easier to parse the next time. See crbug.com/852777 for the new one.