Open Bug 1464685 Opened Last year Updated 4 months ago

Firefox fails to load large session store

Categories

(Firefox :: Session Restore, defect, P4)

61 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: tobbez, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180524181234

Steps to reproduce:

1. Firefox crashed (not what this report is about)
2. When starting up again, Firefox failed to properly load the session restore data in the about:sessionrestore tab, likely because that data was too large
3. I decompressed sessionstore.jsonlz4 and extracted the formData from the about:sessionrestore tab in it and saved that as sessionstore.js.
4. Tried to start Firefox using the resulting file, but it (silently) failed to load the session and just started an empty session (re-compressing as to jsonlz4 did not make difference).
5. Stripped some extension cache data stored by the Tree Style Tab extension, see issue filed against TST for details (https://github.com/piroor/treestyletab/issues/1907 "TST bloats Firefox session store file"). In short, this decreased the uncompressed size of sessionstore.js from 257MiB to 38MiB.
6. Tried to start Firefox using the resulting file, and it worked.

In addition, the session restore data that actually was in the file was ~1.5 months old (despite being written recently), so while just a guess, it seems like Firefox might have issues writing session store files that are too large as well.


Actual results:

Firefox discarded my session.


Expected results:

Firefox should have loaded the session without issue.

Note that while I filed an issue against the TST extension for bloating the file size of the session store, Firefox being unable to load it properly should still count as a bug.
Component: Untriaged → Session Restore
Great to see this bug, had this issue a few weeks ago after a crash, but have not yet reproduced Firefox creating a file it couldn’t read as it stopped writing above the size it could read Bug 1472470.
Maybe while it is in the state being unable to write because of too much data, and then the browser is closed and it writes a file too big that it otherwise would avoid?

Since version 67 I have a similar issue, it partially restores the session.
It is so annoying!

Now has become a pain. It seems to be frozen to some snapshot. Everytime I close and open Firefox it restores a specific set of tabs, never the last ones. Did not matter I have deleted the session store files and set a session store file, it will open those tabs and that's it, never the files, seemingly.
It is a major issue now!

(In reply to Mihai Dobrescu from comment #2)

Since version 67 I have a similar issue, it partially restores the session.

Hi Mihai, first, please back up all recent files from the sessionstore-backups folder in your profile. There may be tabs in recovery.baklz4, previous.jsonlz4, or an upgrade.jsonlz4-timestamp file to recover. https://support.mozilla.org/kb/profiles-where-firefox-stores-user-data

Second, there are other bugs more specific to Firefox 67 to review. I don't see a clear prescription for how to avoid the problem, but using Firefox 68 beta might help.

Hi, tried some fixes, the recovery doesn't help, but the problem lies in some other place, seemingly.
No matter how many attempts to cleanup and recover I did manually, it simply did not pass a specific recovery point in time, meaning it always recovered the tabs before a specific date.
Anyway, I have performed a Piriform CCleaner cleanup with Firefox closed. I do this regularly, with clearing the internet cache set (and download history, but I think it is irrelevant this one). After this, Firefox restores the tabs again. I have also Avast Premier with everything active, including firewall asking for any new rule change, so I don't think malware is involved. Malwarebytes did not find anything, so I guess it's related to the filesystem or files structures on Firefox part, that went messed up or some file access that was not right. I'm out of ideas.

BTW, I know that a bug is not treated until there is time to do it, so it stays in a queue for a long time in some cases, so no excuse is needed.
I hope you understand, sometimes is hard to provide a clue. Regards.

You need to log in before you can comment on or make changes to this bug.