Closed
Bug 791195
Opened 12 years ago
Closed 10 years ago
Session is not restored after Firefox crash
Categories
(Firefox :: Session Restore, defect)
Firefox
Session Restore
Tracking
()
RESOLVED
INVALID
People
(Reporter: pauly, Unassigned)
Details
(Keywords: dataloss, Whiteboard: [notacrash])
Attachments
(1 file)
1.68 KB,
patch
|
Details | Diff | Splinter Review |
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•12 years ago
|
||
Tested on FF 16b3. Reproducible on FF 4.0.1.
Comment 2•12 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.
Comment 3•12 years ago
|
||
Are the missing Pages listed in sessionstore.js at all (checking with a Text Editor)?
Comment 4•12 years ago
|
||
you may find some similar reports amongst https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr;list_id=4533133;field0-0-0=status_whiteboard;field1-0-2=keywords;type0-0-1=substring;field0-0-1=keywords;type1-0-1=allwordssubstr;value1-0-1=dataloss;resolution=---;type1-0-2=substring;classification=Client%20Software;classification=Components;value1-0-2=dataloss;query_format=advanced;value1-0-0=empty%20lost%20missing%20blank;type0-0-0=nowordssubstr;value0-0-0=orange;component=Session%20Restore;field1-0-0=short_desc;field1-0-1=status_whiteboard
Severity: normal → critical
Whiteboard: [notacrash]
Comment 5•12 years ago
|
||
(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•11 years ago
|
||
I've reproduce this on FF 19b6 Win 7 x64 with a dirty profile.
Comment 8•11 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.
Comment 9•11 years ago
|
||
We'll need a solid STR to move forward with this.
Keywords: qawanted,
steps-wanted
Reporter | ||
Comment 10•11 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.
Comment 11•11 years ago
|
||
Tim, given this is intermittent, is there anything Paul can do to provide debugging info outside of STR?
QA Contact: paul.silaghi
Comment 12•11 years ago
|
||
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
Comment 13•11 years ago
|
||
Cornel, how reproducible are those steps for you? Can you please try to come up with a regression window for this bug?
Comment 14•11 years ago
|
||
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
Comment 15•11 years ago
|
||
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
Comment 16•11 years ago
|
||
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*.
Comment 17•11 years ago
|
||
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)
Comment 18•11 years ago
|
||
Is this reliably reproducible for you Mihai? If so, please find a regression range.
Comment 19•11 years ago
|
||
(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)
Comment 20•11 years ago
|
||
I'm not able to test on previous versions of FF 4.0 because Crash me addon in not compatible with those versions.
Comment 21•11 years ago
|
||
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
Updated•11 years ago
|
Flags: needinfo?(gavin.sharp)
Updated•11 years ago
|
Flags: needinfo?(ttaubert)
Comment 22•11 years ago
|
||
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)
Comment 23•11 years ago
|
||
(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?
Comment 24•11 years ago
|
||
Tim, how are you initiating the crash? Can you share your script?
Comment 25•11 years ago
|
||
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
Comment 26•11 years ago
|
||
(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)
Comment 27•11 years ago
|
||
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)
Comment 28•11 years ago
|
||
(In reply to Mihai Morar, QA (:MihaiMorar) from comment #25) > Still happening on FF 24 RC using Windows 7 x64. What about Nightly?
Comment 29•11 years ago
|
||
(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
Comment 30•11 years ago
|
||
(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.
Comment 31•10 years ago
|
||
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.
Comment 32•10 years ago
|
||
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)
Comment 33•10 years ago
|
||
(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)
Comment 34•10 years ago
|
||
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
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•