This only affects my main user profile. Doesn't crash on a fresh --user-data-dir. So... downgrading priority but there is still a problem here.

Assigning to droger who added that DCHECK in r502611. I will continue to investigate exactly what's different about my user profile.

Ah, the check fail is happening when I try to open the stub-user account that's created by tests (therefore, I'm not sure how this is passing browser tests).

Background: When I run browser_tests locally (at least, I think it's browser_tests but... some tests for sure), it creates a new user in /usr/local/google/home/mgiuca/.config/chromium/test-user, and sets that user as the current user. When I later run Chromium normally, I'm signed in as test-user. (This user name is "stub-user@example.com" and probably has some fake GAIA credentials which is why it's hitting this check.)

Eventually, I stopped bothering to switch back from stub-user and just started using stub-user as my main testing profile. This now crashes on startup. My other users don't.

So, maybe this isn't a thing any more (perhaps stub-user is left over from an old time and isn't being created any more). Still, it's not good if an old user profile can cause a DCHECK on startup. I'll leave it to you to investigate, or WontFix, depending on how severe you think this is.

#2 Correction: stub-user isn't created by browser_tests. It's created by running a Chrome OS build.

So the steps to reproduce are:

1. Make a regular Linux build.
2. Make a build with target_os = "chromeos".
3. Run the Chrome OS build. This changes the currently selected user to stub-user@example.com.
4. Run the regular build. This crashes on startup.

The work-around is to always run your Chrome OS build in a separate --user-data-dir so that it doesn't switch the currently selected user in your main data dir. But it's much easier if you regularly develop Chrome OS and Chrome to just always test using the stub-user profile. Now that is not possible.

(Also if I ever use Chrome OS without --user-data-dir, as I have just done, I brick my user data dir unless I can go in and manually change the preference, and I can't find an easy way to do this. Also I can't share test data between the two accounts.)

I will look into this.

I'm not sure I understand all the steps (basically you're using a ChromeOS specific account on a linux client?), and for sure I've never done ChromeOS builds, but hopefully I will manage to fix this anyway.

I'm doing a Chrome OS build on Linux which basically builds a "fake" version of Chrome OS for development and testing.

It's a bit dodgy (i.e., it creates this strange user account) and it's not something users would normally see. But it's pretty much the normal way we do CrOS development so it's kind of an important developer use case.

Yes, I am doing something a bit dodgy, using the account created for CrOS with my normal Linux Chromium build, but it's worked fine for 4 years up until the above CL.

Commenting out the DCHECK makes it work fine as far as I can tell, so perhaps the DCHECK could be made a bit more generous or something.

#4 to elaborate a bit on the steps to build Chrome OS:

1. Make a new out directory ("gn gen out/cros"). # call this whatever you like
2. cp out/Default/args.gn out/cros  # copy across your normal args file.
3. gn args out/cros
4. Add to this file: target_os = "chromeos", and save.
5. Build the "chrome" target in that out directory, and then run out/cros/chrome.

Thanks for looking into it!

I could repro the bug with these steps:
- sign in to Chrome
- quit Chrome
- delete the token from the token_service table in the Web Data database
- start Chrome

CC msarda: it seems that when the token for the main account is missing, Chrome does not actually detect it.

Looks likes this happens because FireRefreshTokensLoaded() is called before setting the INVALID_GAIA_CREDENTIALS error. 

In MutableProfileOAuth2TokenServiceDelegate::OnWebDataServiceRequestDone():
https://cs.chromium.org/chromium/src/chrome/browser/signin/mutable_profile_oauth2_token_service_delegate.cc?rcl=533744aa7772db7ede651fc9639d9598b3ee7420&l=342

I don't know if this is a bug or not, but this is clearly against the assumption that is made in the account reconcilor.

Heads-up: Running try jobs on tentative fix: https://chromium-review.googlesource.com/c/chromium/src/+/681434

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

commit 0b9b8961b6c24ddc8ca6f733a586415b98db9e9e
Author: David Roger <droger@chromium.org>
Date: Mon Sep 25 12:28:04 2017

[signin] Call FireRefreshTokensLoaded after initializing the main token

In MutableProfileOAuth2TokenServiceDelegate::OnWebDataServiceRequestDone
FireRefreshTokensLoaded() was called before the token for the Sync
account is fully initialized.

In particular, when the token is missing, a placeholder token with a
INVALID_GAIA_CREDENTIALS error is inserted in the token service as part
of the loading flow.

FireRefreshTokensLoaded() should be called after this is done. Failing
to do this violates the assumption that the Sync account must have a
(possibly invalid) token at all times.

Bug:  766901 
Change-Id: I9f30b7bf2feef3376fc8e30095a1ae9e041d73b1
Reviewed-on: https://chromium-review.googlesource.com/681434
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Commit-Queue: David Roger <droger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504031}
[modify] https://crrev.com/0b9b8961b6c24ddc8ca6f733a586415b98db9e9e/chrome/browser/signin/mutable_profile_oauth2_token_service_delegate.cc

Please reopen if you can still repro.

It's fixed for me! Thanks!