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

Issue metadata

Status: Fixed
User never visited
Closed: Jun 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 127607: REGRESSION: Multiprofile : Shows Restore message after normal Exit

Reported by, May 10 2012 Project Member

Issue description

Chrome Version       : 20.0.1132.1 (Official Build 136196)

What steps will reproduce the problem?

1. Create couple of profiles
2. Make a Wrench , Exit
3. Launch Chrome again

Provides the message "Google Chrome did not shut down correctly .Click Restore"

What is the expected result?

Should not not provide the message.

What happens instead?

See attachment. After the crash the user data folder gets corrupted .Crash Id not created.

Please provide any additional information below. Attach a screenshot if

Will provide the bisect Info soon.
147 KB View Download

Comment 1 by, May 10 2012

Is this related to the same issues we're seeing with  issue 127513 ?

Comment 2 by, May 10 2012

Labels: Action-BisectNeeded
I think  issue 127513  is a versioning conflict when opening the web database, and this one is an error reading profile data (most likely preferences, which are JSON).

Also, I'm not really sure data gets corrupted here. This is a newly created profile, so there isn't much data to corrupt. It looks more like it isn't properly marked as a clean shutdown.

Comment 3 by, May 10 2012


Comment 4 by, May 11 2012

I can't reproduce this myself in the latest Canary (20.0.1133.0) on Windows.

Comment 5 by, May 11 2012

Can we verify that this is still happening in 1132.3?

Comment 6 by, May 11 2012

I am still encountering the issue with the latest dev build 20.0.1132.3.
Need to repeat the steps mentioned couple of times.

Working on the bisect.

Comment 7 by, May 11 2012

Did a manual bisect . 

Worked till - 19.0.1049.3
Broken from - 19.0.1055.1

Change List

Looks like couple of changes are made in multiprofile during this period.

Cannot use the bisect tool to reproduce the issue.

Comment 8 by, May 11 2012

Labels: -Action-BisectNeeded
Removing the bisect label, as it is not possible to run the bisect tool for this issue .Since I have to repeat the steps couple of times to reproduce the issue.

Comment 9 by, May 11 2012

I'm having difficulty reproducing this. ligimole, do you have a set of steps to reliably repro this on 1132.3? Do you change any particular settings or visit any particular pages? Thanks.

Comment 10 by, May 11 2012

I do not have any local setup.. I just do a fresh install , create couple of profiles , exit & relaunch again . Repeat this process continuously couple of times and after a while u will encounter  this issue.

Comment 11 by, May 11 2012

@rlp .. Could u pls take a looks into wondering whether it is related to this issue..

Comment 12 by, May 11 2012

Hmm, there's not a lot of info for that crash. Did you encounter it on restart or exit?

Comment 13 by, May 11 2012

I got this from chrome://crashes .. so was suspicious.

Comment 14 by, May 11 2012

Got it. I don't think the profile corruption is the result of a crash or else we should be seeing more reports like that. If that crash starts appearing frequently, we should look deeper.

Comment 15 by, May 12 2012

So the only time this message is shown is when either the history service or web data service fail to initialize. This is why I originally suspected something similar to  issue 127513  and probably also why it works in 1133. However, the fix for 127513 didn't work here. So I'm now looking for changes in how we shutdown the history and web data services to see if we've created a problem there.

Comment 16 by, May 12 2012

Status: Assigned

Comment 17 by, May 15 2012


Marja, I know you've done some work with restarting profiles after crashing. This isn't a crash, but do you have any ideas on what might be causing this?

Comment 18 by, May 15 2012

Maybe the "exit was clean" preference is not written correctly?

You could check the "exited_cleanly" preference in the Preferences file under each profile.

Comment 19 by, May 15 2012

I am still not able to repro this on my machine with either a clean install or building the branch. I just tried again with 1132.8 using the exact same steps I learned from Ligimole. Ligimole, are you still seeing this on 1132.8? If so, can you send me your Preferences file? Thanks.

Comment 20 by, May 15 2012

@rlp .. I am able to reproduce this in a different Win7 system using 20.0.1132.8 , Also am not able to attach the pref zip file since it is exceeding the max attachment limit. I can provide you the test machine if needed.

Comment 21 by, May 15 2012

@ligimole, please ping me when you have a moment. Thanks!

Comment 22 by, May 15 2012

Wait, how big is the compressed Preferences file? Usually it shouldn't be more than maybe a couple of hundred kb, especially with a fresh profile.

Comment 23 by, May 15 2012

Attached the Preferences File
17.7 KB View Download

Comment 24 by, May 15 2012

Attaching the Preferences file after wrench , exit
17.7 KB View Download

Comment 25 by, May 15 2012

Hm, these appear to be completely identical. Also, in both files, the profile.exited_cleanly pref is true :-/

Comment 26 by, May 15 2012

Ok, the Preferences file probably was a red herring. The string displayed in the screenshot does not seem to be the one shown when the Preferences file cannot be read; it's shown when there is an error opening the web or history database (but *not* if it's too new).

Comment 27 by, May 15 2012

We're actually seeing two issues here. One is that restore message at the top which *should* only be shown if profile.exited_cleanly = false. The other issue is the "Your profile could not be opened properly" message which only occurs if there is a problem with the web or history database.

According to @ligimole, the former (restore message) occurs every time, but the latter (profile message) only occurs sometimes.

Comment 28 by, May 15 2012

Okay, here's something interesting: According to the comment in ProfileImpl::DidLastSessionExitCleanly() it calls GetPrefs() to force loading preferences (which initializes |last_session_exited_cleanly_|), but GetPrefs() doesn't actually load preferences, it just returns |prefs_|. So, if this method is called before preferences are loaded, the value will be uninitialized.

Comment 29 by, May 15 2012

Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
I'm hoping this should be gone in beta. For now, I'm punting to stable.

Comment 30 by, May 15 2012

@bauerb, that is interesting. That may explain why the error isn't consistently reproducible (comment #8) depending on whether the preferences loaded in time.

It looks like last_session_exited_cleanly_ isn't initialized. If we initialize it to true, it should eliminate false negatives although we might end up with some false positives. What we probably want to do is wait until the prefs have been loaded in DidLastSessionExitCleanly().

Comment 31 by, May 15 2012

Although the fact that it doesn't appear in 1133 is suspicious. Or perhaps other events give the prefs time to load properly in that version? :-/

Comment 32 by, May 16 2012

I'm now playing around with a repro machine (thanks, @ligimole) and I think I know what might be going on and it seems I can repro it reliably (on this machine at least).

When a profile is opened (new or otherwise), the preference "exited_cleanly" is written as false. After the profile has exited, it's rewritten to true. So once we exit from the wrench menu, the browser goes about shutting down the profiles. If we restart the browser *before* we've had a chance to write out "exited_cleanly" preference to true, then when browser starts up again, it sees false and gives this error message. I can see that many other files haven't yet been written by the time I'm starting up the new browser process which might also account for the inconsistency in the profile load message.

Consistently, if I wait after shutting down the browser (for example, opening the Preferences file to check on it or just waiting an arbitrary 30 seconds), it opens just fine.

@ligimole, can you double check what I'm finding on your other machine? Do the usual (create a bunch of profiles, shut down via the wrench menu), but then wait 30 seconds before opening the browser once again. Please let me know if that still gives the error. Thanks.

Comment 33 Deleted

Comment 34 by, May 17 2012

@rlp .. I was able to reproduce the same issue in another Win system , using the latest dev build - 20.0.1132.11 (Official Build 137611)

I can provide you the system if needed.

Comment 35 by, May 17 2012

I tried this by waiting for 30 secs ( actually i waited more than that may be a min or so) .. the issue does not show up..

If I quickly relaunches the error message show up.

Comment 36 by, May 17 2012

So what's happening is that when we start up Chrome the second time, the first browser process has not finished writing out profile information. Therefore, the profile information isn't there for second browser process which rightfully sees it as a corrupt profile. We can't simply open up a window in the original browser process because the original one has already gone into shutdown. This is why we see the error when you open up a new Chrome quickly after exit versus waiting.

One suggestion from @pkasting is to have a listener for any other Chrome browser processes before we proceed with startup of the new browser process.

I'm looping in some other folks (@jam, @darin) who hopefully know more about browser shutdown and startup and can advise on this.

+ @jam, @darin

Comment 37 by, May 23 2012

rlp@ any progress?

Comment 38 by, May 23 2012

Unfortunately not yet although this has been my primary focus. Discussion with @jam indicates that this is something that *shouldn't* be happening but is. I'm currently trying to get a build on to the test machine, but having difficulty doing so. I will update when I have more information.

Comment 39 by, May 23 2012

Small update: I've managed to get my build on the test machine. It does not repro with the debug build but it does with my release build. Continuing the search . . .

Comment 40 by, May 23 2012

Labels: Feature-Preferences

Comment 41 by, May 23 2012

Additional update. I am able to repro with a release build. LOG output indicates so far that things are "happening as they should" with respect to order of writing and locking operations, so the search continues . . .

Comment 42 by, May 24 2012

Labels: -Type-Regression Type-Bug
Also, this is not a regression. I have just repro'd it on the current stable version (19.0.1084.52) as well.

Comment 43 by, May 24 2012

Labels: -Type-Bug Type-Regression
Please disregard my previous comment, as I see that @ligimole pointed out that it appeared between 19.0.1049.3 and 19.0.1055.1 (been staring at this too long). Though given that it's in the current stable, I wonder if we're seeing any crash reports from this?

I will be stalled on this due to sheriffing duties next week and it looks like @jam who was assisting me with this is out of town the rest of this week. If there is someone else who is familiar with startup and preference writing that can give me a hand, please let me know. I have log output that documents how the different processes are writing when they shouldn't be.

Comment 44 by, May 24 2012

Using the canary builds, I have narrowed down the range of when it started failing a bit more.

Worked till - 19.0.1049.3 (from @ligimole)
Broken from - 19.0.1051.0

I cannot repro it on 19.0.1050.0 but that build crashes when opening Settings after deleting User Data so it is shaky. But this should narrow the search a bit more.

Comment 45 by, Jun 12 2012

Update: We've tracked it down to r121480. Working on a fix now.

Comment 46 by, Jun 18 2012

Project Member
The following revision refers to this bug:

r142682 | | Mon Jun 18 01:47:57 PDT 2012

Changed paths:

Move the window destruction and registration out of cleanup and into BrowserProcessImpl::EndSession to make sure it happens after profiles are written out.

BUG= 127607 
TEST=Run on slow computer, open three or more profiles, exit from wrench menu, immediately open chrome again. There should be no reports of profile corruption and logs should show that profile writing is not occuring after second chrome starts.

Review URL:

Comment 47 by, Jun 18 2012

Labels: Merge-Requested

Comment 48 by, Jun 18 2012

Labels: -Merge-Requested Merge-Approved

Comment 49 by, Jun 18 2012

Project Member
Labels: merge-merged-1132
The following revision refers to this bug:

r142751 | | Mon Jun 18 10:39:20 PDT 2012

Changed paths:

Merge 142682 - Move the window destruction and registration out of cleanup and into BrowserProcessImpl::EndSession to make sure it happens after profiles are written out.

BUG= 127607 
TEST=Run on slow computer, open three or more profiles, exit from wrench menu, immediately open chrome again. There should be no reports of profile corruption and logs should show that profile writing is not occuring after second chrome starts.

Review URL:
Review URL:

Comment 50 by, Jun 18 2012

Status: Fixed

Comment 51 by, Aug 8 2012

Labels: -Merge-Approved
Remove merge approval label, this release has passed.

Comment 52 by, Aug 8 2012

Remove merge approval label, this release has passed.

Comment 53 by, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 54 by, Oct 17 2012

Labels: -Feature-Preferences Feature-Settings MovedToSettings

Comment 55 by, Mar 9 2013

Project Member
Labels: -Type-Regression -Area-Internals -Mstone-20 -Feature-Profiles -Feature-Settings Type-Bug-Regression Cr-UI-Settings Cr-UI-Browser-Profiles M-20 Cr-Internals

Comment 56 by, Mar 14 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment