1864619 - reproducible session restore failure

Status: NEW

(Firefox :: Session Restore, defect, P3)

Description

[Dietrich Ayala (:dietrich)]

On dev edition, macOS Venture 13.6 (22G120)

I have a session file that reproducibly halts mid-restore. I tried dropping same file in a nightly profile, same thing happens.

Typically this session restores fine, w/ browser restarts fairly often, for many years.

The session is ~2k tabs and from daily-use profile that is ancient - though I think i refreshed it a couple years ago.

The design of the restore feature is that this failure, even with a pathological session, should not be possible.

It is highly likely that whatever the failure cause is, it affects other sessions of varying sizes.

Given that the session was fine for a long time, perhaps it's site-specific data in the file causing the failure.

However, no way to really know until debugged.

I'll reach out backchannel to provide the file.

Comment 1

[Dietrich Ayala (:dietrich)]

using a script from mossop [1] i decompressed the session file.

jq throws no errors when parsing it.

1. https://gist.github.com/autonome/2a3f5f030bf02780c0b7800cdfe2cbcb

Comment 2

[Sam Foster [:sfoster] (he/him)]

(In reply to Dietrich Ayala (:dietrich) from comment #1)

using a script from mossop [1] i decompressed the session file.
jq throws no errors when parsing it.

Agreed, the file itself looks fine. And most of the session restore seems to actually work - if we're seeing the same thing. All 33 windows are created and it looks like all the 2500+ tabs too. But shortly after the browser hangs and I start seeing the "force quit or wait" dialog and I don't think it ever recovers. I that consistent with what you are seeing :dietrich?

Which suggests either one of the pinned or foregrounded tabs which loads is causing the hang, or some other process late in the session restore. I'm continuing to poke at it and try and catch the culprit red-handed with the profiler.

Comment 3

[Dietrich Ayala (:dietrich)]

I'm not seeing hangs - the session restore process seems to complete - but only for partial session data.

Only some of the windows have all their tabs. There's one window that has a lot of tabs, including a few pinned tabs, which is not restored at all. Perhaps that window is where the problem is.

Comment 4

[Sam Foster [:sfoster] (he/him)]

I'm on the hook to provide some findings from the session store file the reporter provided. need-info'ing myself to keep that in sight.

Comment 5

[Sam Foster [:sfoster] (he/him)]

I've done a bit more poking at this.

• I can remove all but the primary window with its 2144 tabs and I still get the hang after the window and tabs are created.
• I can flip all the pinned tabs to be not pinned - this means that won't load until they are selected - with no change to the hang.

I've captured a profile and I'll try to extract some meaning from it. But in the meantime one hypothesis is that we're running into bug 1849393 - by the time the session is restored and control given back to the session store code, its due for its periodic save to disk. And because of the size of the session data it takes so long to serialize and write to disk its immediately due again. I've not checked if this is possible, or if the timer correctly schedules the next write after the previous one is fully complete (vs when it is started.)

That would be a bug, but I'm still not 100% sure I'm reproducing the same issue :dietrich originally reported when restoring this session. I'm able to confirm the windows and all the tabs are created - the session restore completes successfully for what that is worth. It just never goes idle enough to actually interact with the browser after that.

I'll leave the need-info to follow up with some analysis of the profile.