Session is not restored after Firefox crash

RESOLVED INVALID

Status

()

--
critical
RESOLVED INVALID
6 years ago
5 years ago

People

(Reporter: pauly, Unassigned)

Tracking

({dataloss})

Trunk
dataloss
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [notacrash])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
STR:
1. Start FF on a new profile
2. Install the Crash-me Add-on http://ted.mielczarek.org/mozilla/crashme.html
3. Restart to complete the add-on installation
4. Open several tabs
5. Crash Firefox
6. Repeat steps 4 and 5

Actual results:
Tabs are not restored

Expected results:
Tabs should be restored
(Reporter)

Comment 1

6 years ago
Tested on FF 16b3.
Reproducible on FF 4.0.1.

Comment 2

6 years ago
This issue is intermittent and it also reproduces on the latest Nightly. 

When Firefox restarts after the first crash, all my tabs are restored fine. When it restarts after the following crashes, about:sessionrestore gets opened but it doesn't always contain all the tabs that should be there. This looks pretty random since it lost different tabs even when I kept opening the same tabs at step 4.
Keywords: dataloss
Version: 16 Branch → Trunk
Are the missing Pages listed in sessionstore.js at all (checking with a Text Editor)?
(In reply to XtC4UaLL [:xtc4uall] from comment #3)
> Are the missing Pages listed in sessionstore.js at all (checking with a Text
> Editor)?

Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0(In reply to 

The sessionstore.js contains only the following:

{"windows":[{"tabs":[{"entries":[{"url":"about:home","title":"Mozilla Firefox Start Page","ID":0,"docshellID":5,"docIdentifier":0},{"url":"about:","title":"About:","ID":1,"docshellID":5,"owner_b64":"SmIS26zLEdO3ZQBgsLbOywAAAAAAAAAAwAAAAAAAAEY=","docIdentifier":1,"scroll":"0,0"}],"index":2,"hidden":false,"attributes":{}}],"selected":1,"_closedTabs":[],"busy":false,"width":840,"height":1010,"screenX":840,"screenY":0,"sizemode":"normal"}],"selectedWindow":1,"_closedWindows":[],"session":{"state":"running","lastUpdate":1354181895992,"startTime":1354181687095,"recentCrashes":1},"scratchpads":[]}

It should have restored ~10 tabs (youtube, Fb, yahoo, gmail, google maps .. etc)
This bug has been hard to move forward. What's needed to get traction on this bug?
(Reporter)

Comment 7

6 years ago
I've reproduce this on FF 19b6 Win 7 x64 with a dirty profile.

Comment 8

6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0

I've encountered the same behavior with Firefox 20 beta 3 (Build ID: 20130305164032) on Windows 7 (32 bit) with a dirty profile.
We'll need a solid STR to move forward with this.
Keywords: qawanted, steps-wanted
(Reporter)

Comment 10

6 years ago
Don't know if it's possible that. The bug is intermittent, simply crash FF with the addon several times and you'll see the issue in the end. I reproduced it last time with youtube and google search tabs.
Tim, given this is intermittent, is there anything Paul can do to provide debugging info outside of STR?
QA Contact: paul.silaghi
I was able to reproduce it on FF 20 RC using the steps from description.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID:20130326150557
Cornel, how reproducible are those steps for you? Can you please try to come up with a regression window for this bug?
Unfortunately I'm unable to find a regression window because the chance to reproduce it is very small (about 1 of 20-25 attempts). If there's anything else I can help with, please let me know.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130328 Firefox/22.0
Build ID: 20130328031013
This bug is not likely to get developer support until we can provide a regression range and reliable steps to reproduce. Paul and Cornel, if you can't come up with something here I think we might be dead-ended.
Keywords: qawanted → regressionwindow-wanted
If you open a couple of tabs and crash the browser quickly after that, the new tabs might not have been written to disk, yet. Is this bug about losing newly opened tabs or do we also lose whole sessions that have been around for minutes/hours?

I had *lots* of Nightly crashes lately due to popup notifications etc and did not once lose my huge session *knock-on-wood*.
This is happening on 17.0.8 ESR on Windows 8 x86 following same STR from Comment 0.
I had opened 3 tabs: www.cnn.com , www.engadget.com , www.mtv.com .Pin first one (cnn). 

After crash there are 2 results: 
  1. Last tab is opened as being New Tab instead of www.mtv.com 
  2. Last tab is missing (only pined tab first unpined are displayed)

Version: 17.0.8
Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20100101 Firefox/17.0(20130729214632)
Is this reliably reproducible for you Mihai? If so, please find a regression range.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #18)
> Is this reliably reproducible for you Mihai? If so, please find a regression
> range.

> Paul Silaghi [QA] from comment #1
> Tested on FF 16b3.
> Reproducible on FF 4.0.1.

This is not happening all the time and it looks like this is happening even on 4.0.1 build, while Cornel and Ada had reproduced this on FF 20+ builds.

I can see this on 4.0.1 too using Windows 8 x86, but it happens less than on FF 17.0.8 ESR.

Mozilla/5.0 (Windows NT 6.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1(20110413222027)
I'm not able to test on previous versions of FF 4.0 because Crash me addon in not compatible with those versions.
Thanks Mihai. Given what we know about this I think it's safe to assume this bug is not a regression. It's been nearly a year trying to nail this down and I don't think we are any closer. Unfortunately I don't know what else we can do to debug this and I don't think this will be resolved until we do (or until Session Restore is completely refactored). 

Gavin, do you have any advice or know someone who might advise us further on this issue?
Flags: needinfo?(gavin.sharp)
Keywords: regressionwindow-wanted, steps-wanted
Flags: needinfo?(gavin.sharp)
Flags: needinfo?(ttaubert)
So I wrote a script today that crashes Firefox randomly between 0-30s after the browser window is shown, restarts it again, and it would stop once sessionstore failed to restore tabs. I've run it for a while now on a clean profile on Mac, Linux and Windows.

Not a single sessionstore failure in all of the automatic and manual crashes in the last hours. There are other bug reports out there that suggest we may not end up saving data correctly when crashing but as hard as I try I can't reproduce that even a single time.

Is this really still reproducible for others out there? With a Firefox Nightly? Firefox 26?
Flags: needinfo?(ttaubert)
(In reply to Tim Taubert [:ttaubert] from comment #22)
> Is this really still reproducible for others out there? With a Firefox
> Nightly? Firefox 26?

With a clean profile? Without any add-ons?
Tim, how are you initiating the crash? Can you share your script?
Still happening on FF 24 RC using Windows 7 x64.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 BuildID: 20130910160258
(In reply to Tim Taubert [:ttaubert] from comment #22)
> So I wrote a script today that crashes Firefox randomly between 0-30s after
> the browser window is shown, restarts it again, and it would stop once
> sessionstore failed to restore tabs. I've run it for a while now on a clean
> profile on Mac, Linux and Windows.
> 
> Not a single sessionstore failure in all of the automatic and manual crashes
> in the last hours. There are other bug reports out there that suggest we may
> not end up saving data correctly when crashing but as hard as I try I can't
> reproduce that even a single time.

Can you please provide the script so I can continue to investigate this issue on the versions before FF 4.0. Please see Comment 18 and Comment 20.
> Is this really still reproducible for others out there? With a Firefox
> Nightly? Firefox 26?
Flags: needinfo?(ttaubert)
Created attachment 804324 [details] [diff] [review]
crash.patch

That's quite a hacky patch that crashes Firefox shortly after startup. YMMV. This needs the crashme add-on [1] to work.

[1] http://ted.mielczarek.org/mozilla/crashme.html
Flags: needinfo?(ttaubert)
(In reply to Mihai Morar, QA (:MihaiMorar) from comment #25)
> Still happening on FF 24 RC using Windows 7 x64.

What about Nightly?
(In reply to Tim Taubert [:ttaubert] from comment #28)
> (In reply to Mihai Morar, QA (:MihaiMorar) from comment #25)
> > Still happening on FF 24 RC using Windows 7 x64.
> What about Nightly?

I can reproduce on Latest Nightly in 100% cases.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 BuildID: 20130917030214
(In reply to Tim Taubert [:ttaubert] from comment #28)
> (In reply to Mihai Morar, QA (:MihaiMorar) from comment #25)

I am using your Crashme script from Comment 27 for crashing FF.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:27.0) Gecko/20100101 Firefox/27.0

Reproduced on Firefox 27 beta 1(build ID: 20131209204824).
Used three tabs and managed to reproduce this issue twice (the last tab was restored as new tab) out of more than 10 tries.
Cornel, is it only ever the last tab that comes up as blank? We by default only save every 15s max. So if you start up and we write to disk there is a 15s window where things might get lost if you crash the browser. That's a reasonable tradeoff for crash recovery but does of course yield some "false positives" when testing things like this manually.

I would rather close this bug report as invalid, we properly save state every 15s and we just can't write to disk on every tiny change. That's how sessionstore always worked.
Flags: needinfo?(cornel.ionce)
(In reply to Tim Taubert [:ttaubert] from comment #32)
> Cornel, is it only ever the last tab that comes up as blank? We by default
> only save every 15s max. So if you start up and we write to disk there is a
> 15s window where things might get lost if you crash the browser. That's a
> reasonable tradeoff for crash recovery but does of course yield some "false
> positives" when testing things like this manually.
> 
> I would rather close this bug report as invalid, we properly save state
> every 15s and we just can't write to disk on every tiny change. That's how
> sessionstore always worked.

Using more than 5 tabs, not only the last one but the last 2 or 3 were lost.

I've verified using the 15s state save and it seems to work fine. All of the tabs were correctly restored using 2 windows - each of them containing more than 5 tabs.
This only seems to reproduce before the state save you mentioned.
Flags: needinfo?(cornel.ionce)
Yeah, if you open 30 tabs in this 15s window they all might be lost. I'm closing this as invalid now as this is expected behavior i.e. a tradeoff we have to make to not impact Firefox performance too much.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.