1146052 - about:sessionrestore empty after crash

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect)

Description

[Justin Dolske [:Dolske]]

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?

Comment 1

[Justin Dolske [:Dolske]]

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.

Comment 2

[Justin Dolske [:Dolske]]

...nor anything in the browser console with browser.sessionstore.debug enabled.

At least this seems easy to reproduce for me?

Comment 3

[Jesse Ruderman]

[Tracking Requested - why for this release]:

Serious dataloss for users who don't figure out the workaround in comment 0.

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

Did you use your profile for testing with e.g. mozregression? Can you please check if |browser.sessionstore.resume_from_crash| is true?

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

Just reproduced with resume_from_crash=true. Thanks for finding that great way to reproduce :)

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

Let's hope this is really only five points.

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

So... the data isn't gone. It's just in a format we can't parse anymore.

Comment 10

[Tim Taubert [:ttaubert] (inactive)]

Attachment: 0001-Bug-1146052-Fix-empty-about-sessionrestore-after-cra.patch

Comment 11

[Jesse Ruderman]

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?

Comment 13

[Tim Taubert [:ttaubert] (inactive)]

(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?

Comment 14

[Tim Taubert [:ttaubert] (inactive)]

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.

Comment 15

[David Teller [:Yoric] - still alive but not very active]

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.

Comment 16

[Adrian Aichner [:anaran]]

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.

Comment 17

[Tim Taubert [:ttaubert] (inactive)]

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!

Comment 18

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/integration/fx-team/rev/aa1bd6ac6c21

Comment 19

[Hubert Figuiere [:hub]]

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.

Comment 20

[Daniel Veditz [:dveditz]]

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.

Comment 21

[Adrian Aichner [:anaran]]

(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.

Comment 22

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 38 and 39. 
Do we know if this is a recent regression?

Comment 23

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/aa1bd6ac6c21

Comment 24

[Tim Taubert [:ttaubert] (inactive)]

(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.

Comment 25

[Tim Taubert [:ttaubert] (inactive)]

(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.

Comment 26

[Tim Taubert [:ttaubert] (inactive)]

(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+.

Comment 29

[Cornel Ionce [:noni] [Hubs QA]]

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).

Comment 30

[rctgamer3]

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.