Each of these windows used to have 4-5 tabs.

Deleted: Screen Shot 2016-05-06 at 1.15.17 PM.png 239 KB

	Screen Shot 2016-05-06 at 1.15.17 PM.png 239 KB View Download

Does this problem reproduce frequently? If so, can you use a clean profile (so as to not lose all your tabs) and try to grab a bisect?

Next time you quit chrome make a copy of your 'Current Session' file and make a note of what you expect to see (by that I mean how many windows and tabs in each window you had). I would then copy that file to the appropriate place and in a debugger start chrome and see what is supplied to ProcessSessionWindows() in chrome/browser/sessions/session_restore.cc.

If you send me your 'Current Session' file I can take a look at it and tell you what it thinks you had.

Before you do anything else, please make a copy of ~/Library/Application Support/Google/Chrome (I assume that's where Dev writes to, vs. Chrome Canary for Canary). I think the "Default" folder in that folder stores your tab information in "Current Tabs" and "Last Tabs". So if you just hit this snag you might be able to reproduce it by replacing "Current Tabs" with "Last Tabs". But the important thing is to get that folder copied right away before you quit again.

Current tabs and last tabs are used for restore closed tab, not session restore. See my comment 3 as to the file that is used for session restore.

I've seen this several times as well, but it's hard to repro or diagnose given the size of the session.  I'll try to follow up with sky@ about it if I can find the corresponding files.

Re comment 2:
I cannot repro on Canary.

Re comment 3:
My current "Current Session" file is 1.4 MB. I have Time Machine running, and yesterday's "Current Session" file is 1.7 MB.

(This happened before about two weeks ago. The size of my "Current Session" file from the end of March was 2.9 MB. I had about the same number of tabs open.)

Scott, I can send you both. To be precise, one of the tabs that got eaten was a Gmail tab. So perhaps you can answer the question of why the Gmail tab got eaten while some others did not.

sky@ and avi@ - sorry for the confusion in #5. A bit simpler quick test is to:

1. Make a copy of ~/Library/Application Support/Google/Chrome.
2. Make a note of the windows and tabs you have open.
3. Restart Chrome.

If you're missing tabs after the restart, the Current Session file in the copy of your ~/Library/Application Support/Google/Chrome folder should be useful for reproducing the bug.

I actually managed to recover my tabs. I loaded the "Current Session" and "Current Tabs" files from my Time Machine backup into Canary, and copied over links.

Scott, when I did that, not only did the session restore happen quickly, but everything was restored. Does session restore work differently with signed in profiles and non-signed in ones?

The situation is: I restarted Chrome this morning and half my tabs disappeared. Due to Time Machine, I have a copy of the session from before the restart. But when I put that session file into Chrome Canary and open Canary, all the tabs come back, and they all load super fast.

Which is weird. Is there some kind of race condition where restored tabs get dropped if some subsystem isn't ready? Maybe with my full profile the session restore fails because it's bloated and there's a weird race, but with Canary, because it's just a transplant of my session but nothing else from my profile, session restore is happy.

It's hard to say.

I too tried Avi's file and got all the tabs back (at least the gmail one, which was one Avi said was lost).

There are numerous reasons why session restore wouldn't restore a tab, but I fail to see any that would explain the behavior shown here. By that I mean why session restore worked on canary but not dev.

If you had multiple profiles open, the startup path is slightly different, in that we don't run a nested message loop waiting for session restore. I don't readily why or how this would cause problems.

That's a good point... I have multiple profiles with my main Chrome, but Canary has only one. That is something that differs.

But if I start up a second profile, that doesn't change how the Canary behaves.

The other thing that comes to mind is that my Mac was heavily loaded both times tabs were lost, since it was right after startup, whereas the experiment with Canary was when the Mac was completely idle.

I'm tossing random ideas out there; I haven't any solid clues. :(

If you are under memory pressure session restore may defer loading some tabs, but it shouldn't remove them.

I'll try poking at that code path.

Issue 594588 has been merged into this issue.

Looks like we have an older bug where users have been hitting this for quite some time:  issue 365052 .

sky@, can you help investigate what might be happening?  This seems pretty serious.

There's a lead on the cause for this in https://codereview.chromium.org/1968933002/#msg5.  (That CL seemed unrelated at first glance, but apparently there's a race in UnloadController that can make this possible.)

Re comment 21, that actually explains my experience. The snapshot that Canary restored was resurrected from a moment when Chrome was running, so it had all the tabs. If some of the tabs were dropped during shutdown, then the snapshot that dev channel was restoring wasn't the same.

I really like Mikhail's analysis on that CL.

Mac triage marking assigned to sky@

We're closing in on that fix, which explains both this and  issue 365052 .  I'll mark this as a dupe.