Closed Bug 1146052 Opened 5 years ago Closed 5 years ago
about:sessionrestore empty after crash
Nightly has been very crashy for me over the last week (due to bug 1143339 et al). My last two crashes failed to restore the session -- I get the "this is embarrassing" page, but it's empty and the restore-session button is disabled. Thankfully $PROFILE/sessionstore-backups/recovery.bak has contained my full session, within a minute of the crash, and copying it to $PROFILE/sessionstore.js makes session store work. (It would be nice if the UI offered a way to do this, or just figured it out itself!) Mossop mentioned there may be a known E10S bug at play, but I have E10S disabled. Ed and Jesse also reported session-restore failures on IRC, so I fear there may be widespread breakage here. :( I see bug 1143720 just landed in the sessionstore code a couple days ago, any chance that's breaking things?
I can also sporadically (1 of 3 attempts) reproduce this with just a "kill -11 $firefoxpid". I don't see any interesting console output before the crash or after the failed restart in my debug build.
...nor anything in the browser console with browser.sessionstore.debug enabled. At least this seems easy to reproduce for me?
[Tracking Requested - why for this release]: Serious dataloss for users who don't figure out the workaround in comment 0.
Did you use your profile for testing with e.g. mozregression? Can you please check if |browser.sessionstore.resume_from_crash| is true?
Just reproduced with resume_from_crash=true. Thanks for finding that great way to reproduce :)
Let's hope this is really only five points.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Iteration: --- → 39.2 - 23 Mar
Points: --- → 5
So... the data isn't gone. It's just in a format we can't parse anymore.
Points: 5 → 3
Summary: Increase of session restore failures → about:sessionrestore empty after crash
OS: Mac OS X → All
Hardware: x86 → All
Should the patch in bug 1143720 also be delayed for a version or two, so Firefox doesn't lose your session if it uses a crash as an opportunity to update?
(In reply to Jesse Ruderman from comment #11) > Should the patch in bug 1143720 also be delayed for a version or two, so > Firefox doesn't lose your session if it uses a crash as an opportunity to > update? We will by default automatically resume after a crash. If that same session crashes again we will show about:sessionrestore. So only in case a session crashed twice in a row we wouldn't be able to read about:sessionrestore data if Firefox was updated after the second crash. I wish we had updated the format a long time ago. Not sure how likely it is to run into trouble given that you would have to crash twice in a row and update in between. OTOH I wouldn't really mind delaying bug 1143720. We could reduce the delay by uplifting the low-risk changes here maybe?
I think that we would be fine with uplifting the change to Aurora and ESR 38 at the same time. Thus when upgrading from 38 -> 39+ after a crash users will be covered.
Note for later: we should consider versioning the format of sessionstore.js. I believe that this would help avoid the incident in the future by letting us use the backup recovery mechanism transparently.
These failures to restore happen reliably for me when I resume my Windows XP system from hibernation. Is there any insight why firefox crashes every time I hibernate/resume now (did not do that until some days ago)? Firefox crashes while I work on the system typically do restore the session just fine. I did notice from above discussion above that firefox updates some to be part of the picture as well. I'll watch out for restores after crashes after updates.
Adrian, I have no idea why that would happen... Can you maybe file a new bug to track that? We'll fix the empty about:sessionrestore page here and take care of your issue over in the new bug. Thanks!
Attachment #8581579 - Flags: review?(smacleod) → review+
Got hit by this with m-i (why is that kind of breakage no pushed to m-i or m-c...). The patch fix this after I also restore the backup of the backup of the sessionstore.
What do you mean by "crash two times in a row"? This has hit me a couple of times (different profiles maybe?) and I wouldn't describe my crashing as "in a row". I do tend to leave the browser running and just sleep the machine though.
(In reply to Daniel Veditz [:dveditz] from comment #20) > What do you mean by "crash two times in a row"? This has hit me a couple of > times (different profiles maybe?) and I wouldn't describe my crashing as "in > a row". I do tend to leave the browser running and just sleep the machine > though. Do you hibernate the machine? That's what bug 1146934 is about.
Tracking for 38 and 39. Do we know if this is a recent regression?
(In reply to Liz Henry (:lizzard) from comment #22) > Tracking for 38 and 39. > Do we know if this is a recent regression? Yup, very recent :) See bug 1143720.
(In reply to Daniel Veditz [:dveditz] from comment #20) > What do you mean by "crash two times in a row"? This has hit me a couple of > times (different profiles maybe?) and I wouldn't describe my crashing as "in > a row". I do tend to leave the browser running and just sleep the machine > though. If you didn't restart the browser in between those "sessions" then that would be two crashes in a row. A successful shutdown would clear the counter.
(In reply to Tim Taubert [:ttaubert] from comment #14) > I think that we would be fine with uplifting the change to Aurora and ESR 38 > at the same time. Thus when upgrading from 38 -> 39+ after a crash users > will be covered. No, wait. I thought this through again. I think it helps understanding the rest of the comment if you know that about:sessionrestore is a page that has a simple <input> field whose value is the session as a JSON string. That's why the form data format affects this page at all. -- When Firefox crashes we detect at the next startup that we crashed. When we determined we want to show about:sessionrestore (usually when crashing two times in a row) then we prepare a fake session that includes a tab with "about:sessionrestore" and the appropriate form data (i.e. the previous session). The problem in this bug was that Firefox 39 only supports form data format v2 since bug 1143720 landed, but still prepared a fake session using form data format v1. We fixed that by of course using v2 for the fake session. When a user now crashes with Firefox 38 while an update was applied in the background, Firefox will be updated and 39 will run on the next launch. 39 detects that we crashed and will (if necessary) prepare a fake session with format v2. All good here. Now even if you crash with Firefox 38 and quit the browser with an about:sessionrestore tab open, we will *load* the fake session with old v1 but save the about:sessionrestore tab to disk with v2. Thus even old about:sessionrestore tabs should not pose any problems or be suddenly lost if they have been loaded with Firefox 29+.
Verified fixed on Firefox 39.0a2, build ID: 20150415004020. Tested on Windows 7 64-bit, Ubuntu 14.04 x64, Mac OS X 10.9.5 and Windows 8.1 64-bit (MS Pro 2 device).
This doesn't seem to be fixed. Loss of all session data is still happening with 44.0a2 (2015-11-28) If plugin-container crashes during startup including the about:sessionrestore page - about:sessionrestore is empty after reloading the crashed page and as stated before, the only workaround is to copy a previous session backup from the sessionstore-backups folder.
You need to log in before you can comment on or make changes to this bug.