Looks like this corresponded to Browser-process crash report 77002961955b0cc1.

Just observed exactly the same issue when starting ChromeOS Kevin device first time after update to 66.0.3356.0.

Observed this again on ChromeOS 66.0.3356.0 Kevin.

Confirmed on ChromeOS Link 66.0.3358.0 that this is specific to having one or about:flags configured.

When there are flags set we have to re-launch Chrome to load the user session, so this suggests a lower-level bug in session restore, triggering behaviour similar to what you'll see if you crash Chrome, relaunch it, and then exit without having clicked to Restore tabs.

+albert/xiyuan to triage/evelaute 

Likely a side effect of recent sign-in refactor.

Did a quick try on 67.0.3364.0 with a testing gmail account and not able to repro.

wez@, is this happening to your google account only? And could you send a feedback report after seeing it again?

Re #8: Yes, I can repro this with my personal account, if I set at least one flag in about:flags (I set the #memlog flag, FWIW), though this device is still running ChromeOS Canary 66.0.3358.0.

Filed a feedback report from the device after reproing on my corp account - included "xiyuan" and this bug number in the text of the report.

This looks like th feedback report: https://listnr.corp.google.com/report/85160407621

Strange thing is that I don't see the user sign-in [1] or restart to apply flags log [2]. The first one should show up on every sign-in and 2nd one show up when chrome decides to restart to apply user flags.

[1]: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/session/user_session_manager.cc?rcl=028d7f3596fc288af858b934be6fc24cf1152a86&l=551
[2]: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/session/user_session_manager.cc?rcl=413478245d30faa6ff1ab76222c4f111df9635e2&l=852

Ping; can we prioritize getting this resolved, please? It makes it difficult to use ChromeOS day-to-day with any experiments enabled locally.

Moving this to RBS since flags are experimental, we should still get it fixed before stable if this is regression from m65

jdufailt@ can you confirm you are the right responsible for this issue?

Issue 824016 has been merged into this issue.

I did a bisect and found that [1] causes the issue. This reliably reproduces; the easiest way to do so is this:

1) add an owner account
2) add a non-owner account
3) change flags in non-owner account
4) navigate to some url, log out of non-owner
5) log-in to non-owner will be missing the session state

This must be done with a non-owner account, as we use the owner command line arguments on the login screen which avoids the restart. (FYI: this does not apply if the device is enterprise enrolled, since the owner is not the primary account).

1: https://chromium.googlesource.com/chromium/src/+/b13ffda7cd863510c86cd5c804321b350b8800ab

I'm able to reproduce it and will look into it now. 
I wasn't able to reproduce in the ChromeOS on linux build, I guess I have to test on a real device?

I discovered which part of the CL introduced the issue and created a fix to revert that part: https://crrev.com/c/978214

I have no idea why this happening and why it only happens on ChromeOS with non-OWNER users that have flags defined.
I will try to dig a bit more into it on Monday and try to find out why it is happening but if that is not successful we can submit and merge the CL to fix the issue.

I just experienced this under ChromeOS 66.0.3359.48 without any flags set. This is an enterprise device, so presumably all accounts are non-owner.

Re #18 I suspect having --site-per-process set via policy (as most of us do) would trigger this as well (it's a policy that triggers a commandline change. Long story.)

Feedback reports:

https://listnr.corp.google.com/report/85224928608
https://listnr.corp.google.com/report/85220342521

I noticed that SessionService is created twice on ChromeOS. 
Once from ProfileManager::CreateInitialProfile and another time in FinishSwitchLanguage. After the service is created, BaseSessionService::Save() gets called. 
Before my change the method would return early because there are no commands to save. Now it will succeed and initialize the SessionBackend. SessionBackend::Init() calls SessionBackend::MoveCurrentSessionToLastSession(). 
Previously the SessionService that was created first would not initialize its Backend, now it does, so the Session is moved to last session twice, effectively deleting it.

I send the CL to restore the old behavior for review but this might be a deeper issue as any change that leads to an earlier initialization of SessionBackend would trigger this problem again.

first:
#3 0x5f72ac9c0c4b SessionService::SessionService()
#4 0x5f72ac9c4ad2 SessionServiceFactory::BuildServiceInstanceFor()
#5 0x5f72ae6752f5 BrowserContextKeyedServiceFactory::BuildServiceInstanceFor()
#6 0x5f72ae193207 KeyedServiceFactory::GetServiceForContext()
#7 0x5f72ae194519 DependencyManager::CreateContextServices()
#8 0x5f72ae674e4c BrowserContextDependencyManager::DoCreateBrowserContextServices()
#9 0x5f72aca83c82 ProfileImpl::OnLocaleReady()
#10 0x5f72aca8113a ProfileImpl::OnPrefsLoaded()
#11 0x5f72aca80e77 ProfileImpl::ProfileImpl()
#12 0x5f72aca7f231 Profile::CreateProfile()
#13 0x5f72ac9096e2 ProfileManager::CreateProfileHelper()
#14 0x5f72ac903f77 ProfileManager::CreateAndInitializeProfile()
#15 0x5f72ac903c74 ProfileManager::GetProfile()
#16 0x5f72ac903b92 ProfileManager::CreateInitialProfile()
#17 0x5f72ac883aa0 ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
#18 0x5f72ac8830da ChromeBrowserMainParts::PreMainMessageLoopRun()
#19 0x5f72abc01218 chromeos::ChromeBrowserMainPartsChromeos::PreMainMessageLoopRun()

second:
#1 0x5f72ab89c5ca sessions::SessionBackend::SessionBackend()
#2 0x5f72ab898374 sessions::BaseSessionService::BaseSessionService()
#3 0x5f72ac9c0c4b SessionService::SessionService()
#4 0x5f72ac9c4ad2 SessionServiceFactory::BuildServiceInstanceFor()
#5 0x5f72ae6752f5 BrowserContextKeyedServiceFactory::BuildServiceInstanceFor()
#6 0x5f72ae193207 KeyedServiceFactory::GetServiceForContext()
#7 0x5f72ae194519 DependencyManager::CreateContextServices()
#8 0x5f72ae674e4c BrowserContextDependencyManager::DoCreateBrowserContextServices()
#9 0x5f72aca83c82 ProfileImpl::OnLocaleReady()
#10 0x5f72abbf2364 chromeos::(anonymous namespace)::FinishSwitchLanguage()

Are both calls for the same Profile* ? 

ProfileManager::CreateInitialProfile is called on browser start. Its behavior depends on whether there were user sessions (--login-user=... passed from session_manager daemon).

If there were no user sessions, browser should land on the login screen and it should load the sign-in profile (aka 'Default' profile). SessionService is not needed there since we should not have state in sign-in profile.

If there were user sessions, this is a crash-n-restart case and it loads the user profile. SessionService is needed there. However, if this is the case, the 2nd call should not happen. The 2nd call should only happen on the user sign-in code path and not the crash-n-restore case.

Oh right, these are two different profiles:

The first profile that is initialized has a random id:
 u-b7ed0d128a11249ae6bc55f9c138d398bd80331b
The other one is the default profile.

I never had to debug ChromeOS issues before, what is the first profile?

The one prefixed with "u-" is a user profile. Is that the one in the first call (from ProfileManager::CreateInitialProfile)? If so, you are undergoing a browser restart (probably due to user flags or user policy switch that needs to be added when transition from login screen to user session).

The default profile is used for the login/lock screen and it should not have user state in it. AFAIK, FinishSwitchLanguage should not be happening to it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bd6d95223165080a5c21884c41afa265c8a873b4

commit bd6d95223165080a5c21884c41afa265c8a873b4
Author: Christian Dullweber <dullweber@chromium.org>
Date: Tue Mar 27 09:13:52 2018

Fix session restore on ChromeOS

SessionRestore on Chrome OS in a non-OWNER profile and with any flag
enabled doesn't work correctly after logout/login.
This was caused by the change to allow saving a session file
without commands. (https://crrev.com/c/899249)
This CL reverts the problematic parts and fixes session restore.

Bug:  816586 
Change-Id: I4a5050c532143c4fa9990e153952a82b72e3385f
Reviewed-on: https://chromium-review.googlesource.com/978214
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546071}
[modify] https://crrev.com/bd6d95223165080a5c21884c41afa265c8a873b4/components/sessions/core/base_session_service.cc
[modify] https://crrev.com/bd6d95223165080a5c21884c41afa265c8a873b4/components/sessions/core/persistent_tab_restore_service.cc
[modify] https://crrev.com/bd6d95223165080a5c21884c41afa265c8a873b4/components/sessions/core/session_backend.cc

Requesting merge approval for the above CL, which is a partial revert of https://crrev.com/c/899249. 
It fixes a regression in M66 that leads to broken session restore for some ChromeOS users.

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/aec83a2222096b83b98b150f366d00dea0d028b7

commit aec83a2222096b83b98b150f366d00dea0d028b7
Author: Christian Dullweber <dullweber@chromium.org>
Date: Thu Mar 29 08:12:51 2018

Fix session restore on ChromeOS

SessionRestore on Chrome OS in a non-OWNER profile and with any flag
enabled doesn't work correctly after logout/login.
This was caused by the change to allow saving a session file
without commands. (https://crrev.com/c/899249)
This CL reverts the problematic parts and fixes session restore.

Bug:  816586 
Change-Id: I4a5050c532143c4fa9990e153952a82b72e3385f
Reviewed-on: https://chromium-review.googlesource.com/978214
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#546071}(cherry picked from commit bd6d95223165080a5c21884c41afa265c8a873b4)
Reviewed-on: https://chromium-review.googlesource.com/985852
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#492}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/aec83a2222096b83b98b150f366d00dea0d028b7/components/sessions/core/base_session_service.cc
[modify] https://crrev.com/aec83a2222096b83b98b150f366d00dea0d028b7/components/sessions/core/persistent_tab_restore_service.cc
[modify] https://crrev.com/aec83a2222096b83b98b150f366d00dea0d028b7/components/sessions/core/session_backend.cc

Thanks

 Issue 821062  has been merged into this issue.

 Issue 827461  has been merged into this issue.