Closed Bug 1003300 Opened 12 years ago Closed 10 years ago

Firefox always restarts with a nearly empty session after a crash

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: catlee, Unassigned)

References

Details

(Keywords: dataloss, steps-wanted)

Attachments

(3 files)

sessionstore.json
575 bytes, application/json
Details
sessionstore.bak
592 bytes, application/x-trash
Details
empty-sessions-to-restore.png
45.59 KB, image/png
Details
Lately after I restart nightly after a crash, I get a single window with all my pinned tabs, but none of my other open tabs present. There's a single "about:home" tab open. sessionstore.js looks ok prior to restarting. After the restart, sessionstore.bak.js looks like it's a copy of the original sessionstore.js, and the new sessionstore.js is much smaller. I can copy sessionstore.bak.js to sessionstore.js after cleaning quitting firefox, and starting up again I get my original session correctly restored.
There are some reports out there that say crashing the browser might corrupt the session file and/or makes us the wrong thing when trying to restore a session. I tried to reproduce this multiple times on multiple operating systems without success. It would be great to get some more insight and maybe a reliable STR? Might be related to bug 999101, bug 972944?
Flags: firefox-backlog+
Keywords: qawanted
Bug 696684 might also be related.
Bug 1008005 and bug 1020831 might be dupes as well.
When Firefox crashes shortly after startup (when some tabs haven't finished loading?), I often lose most of my tabs. However I'm normally using the Tab Mix Plus extension, and that bug may be there. But... I could also reproduce the problem with no extensions and Firefox's default session restore, but with browser.sessionstore.restore_on_demand set to false (i.e. in the Preferences UI, Tabs, "Don't load tabs until selected" unticked), so that tabs can still be loading a few dozens of seconds after startup. I did that by typing Ctrl-\ just after starting Firefox to emulate a crash. The result was that I just got my home page after restarting Firefox. Tested with: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0
See Also: → 1025651
Doesn't seem to me that bug 696684 (a partial restore) would be related to this, unless a second attempt using the same sessionstore.js restores all tabs. And comment 0, specifically "I can copy sessionstore.bak.js to sessionstore.js after cleaning quitting firefox, and starting up again I get my original session correctly restored.", conflicts with the theory of possible corruption. Might there be a reason other than corruption for the file to be reset? I've had two or three cases in the past month where I got no session restore dialog, and as I recall sessionstore.js looked fine (not zeroed out) and restored fine on a second startup.
In the test I've just done, my test profile contained: -rw------- 1 19541 2014-06-17 01:34:14 sessionstore.js -rw------- 1 8622 2014-06-15 16:51:01 sessionstore.bak then I typed "firefox -no-remote -safe-mode -P test" and, while the tabs were loading, Ctrl-C. Then my test profile contained: -rw------- 1 19541 2014-06-17 01:34:14 sessionstore.js -rw------- 1 8622 2014-06-15 16:51:01 sessionstore.bak i.e. the same thing, but when I typed "firefox -no-remote -safe-mode -P test", I got only one tab (with my home page), with no warnings or errors. Why isn't sessionstore.js taken into account? After quitting Firefox, my test profile contained: -rw------- 1 623 2014-06-17 01:36:13 sessionstore.js -rw------- 1 19541 2014-06-17 01:34:14 sessionstore.bak Then I did: $ cp sessionstore.bak sessionstore.js $ firefox -no-remote -safe-mode -P test and got my tabs back.
Possibly also related: bug 1025651
this is super annoying, anything I can do to help debug? It's 100% reproducible on my machine if I kill firefox and restart.
It just happened to me after a crash: https://crash-stats.mozilla.com/report/index/6b91ea62-62fb-4572-a9a1-e0f942140713 sessionstore.bak showed to me some kind of corruption going on with the session store file. The file starts with a whole bunch of 'å©' characters and after that, the normal json with the various tab entries sort of starts.
Tim, see comment 9. Chris say he can reproduce it every time on his machine.
Flags: needinfo?(ttaubert)
Chris, can you try this in a build that contains bug 883609? It should make Session Restore much more resilient to such issues.
Keywords: dataloss
I'm on nightly built from https://hg.mozilla.org/mozilla-central/rev/b0701d069bf9 right now, so that should be sufficiently new, and I can still reproduce this issue.
Copying sessionstore-backups/recovery.bak to sessionstore.js restores my previous session correctly.
Normally, after a crash, you should have *no* sessionstore.js file (unless it's a startup crash). Is that the case?
Flags: needinfo?(catlee)
That's correct.
Flags: needinfo?(catlee)
(In reply to Vincent Lefevre from comment #7) > i.e. the same thing, but when I typed "firefox -no-remote -safe-mode -P > test", I got only one tab (with my home page), with no warnings or errors. > Why isn't sessionstore.js taken into account? Chris are you also talking about crashes that take place during startup or shortly afterwards (say less than ~10s)? If so, it might be that the checkpoints file has not been committed to disk yet. I'm not sure how that could cause your issue, but this causes us to follow a different codepath from the usual initialization. Also, Chris, are you talking about Firefox crashes or OS crashes/hardware crashes/power off?
Assignee: nobody → dteller
Flags: needinfo?(catlee)
I haven't noticed it being restricted to certain types of crashes. I've had it happen when Firefox has been running a short or a long time. The cause of the crash is sometimes Firefox itself, but I can also reproduce simply by killing the Firefox process. Other causes would be things like X restarting, or machine hanging. Basically any time Firefox isn't shut down cleanly, it starts up with the mostly empty session. It's very odd that all my app-tabs are preserved though.
Flags: needinfo?(catlee)
Ok, so it's most likely not the CrashManager checkpoints. Can you look in recovery.js after a crash and see whether 1/ it is valid JSON; 2/ it contains the expected data?
Flags: needinfo?(catlee)
Stupid question, is this reproducible in safe mode? Are you using any session related add-ons, Chris?
Flags: needinfo?(ttaubert)
Is this still reproducible in latest builds? If so, is it as simple as killing fx for str's. Also in safe-mode?
Keywords: qawanted → steps-wanted
It's still reproducible. After a crash I have no sessionstore.js file. sessionstore-backups/recovery.js is valid, but restoring from that doesn't restore my session. I need to copy sessionstore-backups/recovery.bak to sessionstore.js instead. Interestingly once firefox is back in good shape, I can shut it down cleanly, delete sessionstore.js, copy recovery.js over, and firefox starts back up properly. It is reproducible in safe-mode.
Flags: needinfo?(catlee)
So it seems that recovery.js is a valid JSON file? Does it restore anything from that or nothing? In case of a crash it would make sense that recovery.js could be corrupted but in that case we should just ignore it and use recovery.bak. Having no sessionstore.js file after a crash is expected as we only write that on clean shutdown. All the current state is contained in recovery.js. Before writing to recovery.js we move the previous recovery.js to recovery.bak. In case the write isn't successful or we crash before flushing we would then use the .bak file.
Yeah, recovery.js is a valid json file. It restores a session with a single window, all my app tabs, and one blank tab open.
Mmmh... Could something be overwriting recovery.js?
Not actively working on this.
Assignee: dteller → nobody
Attached file sessionstore.json —
I get several crashes per day with seamonkey. Mostly I get offered by tabs to be restored but this time, I got an empty window. User agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 Build identifier: 20151122033039 -rw------- 1 mmokrejs mmokrejs 460 Dec 5 15:22 sessionstore.bak -rw------- 1 mmokrejs mmokrejs 592 Dec 5 15:23 sessionstore.json -rw------- 1 mmokrejs mmokrejs 4803584 Dec 5 15:23 webappsstore.sqlite I would say there should be installed a road block in mozilla code so that sessiostore.bak is never overwritten by something giving less than 600B. I am attaching both files and a screen dump.
Attached file sessionstore.bak —
And I do not have any recovery.js file.
(In reply to Chris AtLee [:catlee] from comment #22) > It's still reproducible. After a crash I have no sessionstore.js file. Chris, do you still see this problem?
Severity: normal → critical
Flags: needinfo?(catlee)
no, I get all my tabs restored after a crash now
Flags: needinfo?(catlee)
great. then let's close this. If anyone still sees a problem perhaps we reopen bug 767440 (if users there still see a problem) or file a new bug report
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: