Possibly relevant Googler report:

"Updated chrome today, and chrome didn't restart right away. I thought I might be about to run into the same symptoms so I started to check for zombie processes. Then chrome did restart itself without issue. I didn't time it, but I would guestimate that the total delay between chrome closing and restarting again was almost a minute. I'm guessing in the past issue was related to me restarting chrome manually before it had time to finish whatever it was working on and restart itself."

If this could in fact cause locked-profile sorts of problems, then perhaps we need to find out what could be causing such a long time delay around restart and try to minimize that window?

The changes we landed in  issue 455749  are available in M54+. We offer the user the ability to send a feedback report from within the profile error page, which we pre-populate with diagnostic info about the corrupt sql database file. 

We need to look at those feedback reports. They should be filed under the category "FEEDBACK_PROFILE_ERROR".

More anecdotal data suggests that this could be a zombie process.  If so, the process seems to persist for hours after the upgrade.

BTW, the symptom of this error in the affected Googler's case was that local navigations (of any type) failed to appear on chrome://history (which probably means they failed to be written at all), but synced-in navigations from another device continued to appear there.

Yes, the history database is the source of the majority of those errors.

--Chrome Identity automated triaging--

This bug is Untriaged and has gone for two weeks without any activity, so it is being moved to Available. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

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

 Issue 680985  has been merged into this issue.

This is still happening and I'm getting reports from Techstop and Googlers.  Every time we upgrade the stable version we break intranet users.  Upgrading to P1.  I don't know how to help get forward progress here, but please try and escalate this from a planning perspective so that we can devote resources to it.

afakhry@ - do you have bandwidth to look into this?

I can probably look at it next week. Most probably it's the History database that's causing the trouble. I'm not sure what can be done at this stage since we already try to recover the database when we detect corruption.

Clues are that this seems to happen almost every time we upgrade the Chrome version, and restarting seems to fix things for people.  That sounds almost like a locking-type issue to me, or an issue of upgrade-related corruption that we recover from but don't recover from until a restart.

I'm much more inclined towards locking-type issues.  Upgrade-related corruption seems unlikely to continue across multiple releases.

History is mentioned.  We use a profile-level lock which should keep competing readers out in the first place, but we also leave the SQLite-level locking in place.  So for History, there shouldn't be a way to actually corrupt things (other than the standard option of screwing up the filesystem, which should not happen here).  But it could be a problem if someone is messing up the startup/shutdown flow, so that the profile-level lock is not properly scoping the SQLite-level lock.

I would expect to see error logging on this kind of problem.  On OSX you should be able to find it in Console.app, I don't know where one would look on Linux or Windows for results from the default launcher.

What's the possibility of something malicious clobbering those DB files on Windows? Do we have any sort of protection against that?

I don't know, but many reports of this are from Googlers on (I assume) Linux, and it seems very unlikely those issues are caused by something malicious clobbering the DB.

(Could it be something non-malicious locking the file?  Maybe something security software-related that is trying to read the file after we touch it or something?)

I experienced this issue, as indicated in comment 3 and 4, it was due to the old chrome not shutting down properly.  Adding detection for this (other than an error at startup about not being able to read the profile) would probably go a long way towards helping Googlers who experience this on Linux.

Note: This is still happening, now to Googlers updating to M57.

Issue 701419 has been merged into this issue.

I don't think I will have any time to work on this soon. Assigning to shess@ who has more knowledge about the History DB, which is the major cause of this problem.

Updating from v57.0.2987.98 to v57.0.2987.110 resolved the issue in my case.

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

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

This bug is marked as Pri-1 but shess@ appears to have left Google. Is there anyone else who can take ownership of this bug?

Also, does this still appear to be happening to Googlers (e.g. in the M58 update)?

Yes.  I've been getting a lot of messages about it in the last few weeks, including one today.

Got it. Peter, do you have any ideas for who would be a good owner? Sounds like an issue with the History DB.

+Rachel for desktop as well.

I think we're going to have to spin up someone.  There are no "good owners" in the project that I know of; even shess wasn't really up on this stuff AFAIK.

Given that, I don't know who good candidates are.  Someone with an interest in DBs, coherency, disk I/O, etc.?

+Nicolas is anyone on the Sync team familiar with the History DB code?

ccing win leads and Stan (who might have the familiarity and interest to take this on). Any names come to mind?

forshaw@ - This sounds oddly similar to the issue Widevine was hitting, if it's not just Defender/Bit9 misbehaving. Any thoughts?

Is it Windows specific or not? I can't tell from skimming the entries whether it's only on that one platform. I can't think of anything off hand, however doing a quick search for GetMappedFileName does show a few hits. For example IsRunningOldChrome in upgrade_util_win.cc, that certainly could be a candidate if somehow the old chrome is still running but getting the mapped name for the exe indicates that it's still chrome.exe (rather than old_chrome.exe) something bad might happen (such as not upgrading the DBs or something). It's worth a poke I guess.

At any rate that code should probably be replaced with a call to QueryFullProcessImageName which should return the correct result as we don't have to worry about < Win 7.

> Is it Windows specific or not?
This occurs on Linux too

Definitely not Windows-specific.  Indeed, I'm not even sure whether it happens on Windows; the main platform I'm aware of is Linux.

I wonder if issue 477975 (HistoryService blocks shutdown process) is related?

 Issue 731737  has been merged into this issue.

If this is Linux only, should it still be marked as P1?

If we do think it's P1, we should find someone to take ownership, since this has been open for a while.

#36 -  issue 731737  happened on Windows, so this is not a Linux only issue.

(Assuming I duped correctly.)

The fact that Googlers flood me with complaints on every update makes me worried.  If we knew for sure that this was Google-specific and Linux-specific, it would not be P1.  But it sounds like the latter is untrue and I have no reason to believe the former is true.

There are a variety of cryptic effects here that make it hard for end users to accurately report this, and one of the most obvious effects is on handling of intranet URLs in the omnibox, which will only affect enterprise users (who seem even less likely to report bugs).  So I would expect that bug volume would not be a good indicator of end-user impact.  I don't know if we have sufficient metrics to measure this effect in a more accurate way.

I think at least until we can demonstrate there's something Google- or Linux-specific about this, it is P1.

This is neither Google- nor Linux- specific. Please take a look at the following UMA timeline: https://uma.googleplex.com/p/chrome/timeline_v2/?sid=2ca1ac87d8a658fe1bde1b6586a56e10

Which plots the Profile Errors on Windows. The interesting thing is that the "Preferences Error" type took over the "History DB" type. and now it's the majority. 

Rachel - can you get this triaged/prioritized on the Desktop side? Or should we loop someone in from the Enterprise team?

I'm not sure who to assign this to. Jschuh? The UMA link in #39 shows fairly high incidence

It should probably be someone working on sqlite.

I really don't know who should take a look at this. It seems like you want people familiar with profiles and the installer have a discussion.

On Windows, Chrome's installer doesn't touch user prefs or any of the databases in there. My guess would be that the process singleton is involved. Maybe there's a race that becomes more likely during restart-to-update? +gab, who may remember a thing or two about the singleton.

I don't how the restart path works. But if it's possible that this would happen if we relinquish the process singleton before properly dialing down DBs/prefs. I know the long shutdown path takes care of this but I'm not familiar with the other paths (e.g. fast restart).

I've mostly seen this after cold starts. For example, Chrome updates but isn't restarted, Chrome is closed before shutting down the computer (Linux), power on the computer, then open Chrome after signing in.

Oh this is after OS restarts, not Chrome restarts?

Le jeu. 27 juil. 2017 13:25, ddorwin via monorail <
monorail+v2.1614812178@chromium.org> a écrit :

I've experienced this after just a chrome restart before

This is marked as P1, but there is no owner for this. I'm moving this to P2.

@Mihai, see comments #36-39 about priority. I also thought it should be marked as P2. Given that we haven't updated this since July, I'm definitely inclined to mark this as P2 at this point. If it's P!, then hopefully someone on the desktop team can take a look at this ASAP 

--Chrome Identity automated triaging--

This bug is Available and has gone one year without any activity. If another month passes without any activity, this bug will be closed out. Please provide an update with the latest status for this bug. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

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

--Chrome Identity automated triaging--

This available, signin or profiles-related bug has gone at least 30 days since the last automated post without any further update. This bug will be closed out due to inactivity. Please re-open the bug and provide an update if it is still a valid or reproducible bug. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

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

Not fixed