903621 - sessionstore protection lost. NO "out of memory" warning/error

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Wayne Mery (:wsmwk)]

+++ This bug was initially created as a clone of Bug #581510 +++

I've find myself in a situation, via a series of crashes (bug 858791 comment 7) and what not where sessionstore.js is 24MB on startup, and is not being saved thereafter. Please fix this dataloss scenario.

I'm not finding any indication in error console (mentioned in bug 581510) that there is a problem - perhaps no error message because of the recent changes to sessionstore.  But the symptoms are similar what's involved in bug 581510 - crazy jank, not exceptionally high memory usage, sessionstore.js not changing.

Comment 1

[Wayne Mery (:wsmwk)]

Today I found such a message in error console.
"Could not write the session state file ...\sessionstore.js [object WorkErrorEvent] _SessionFile.jsm:228"
and
"Exception..."'Out of memory' when calling method: [nsIObserver:observe]" nsresult: "0x8057001e" (NS_ERROR_XPC_JS_THREW_STRING) ..."

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

Interesting. I have no idea how to reproduce this, though. My machine works fine with a 50mb sessionstore.js file. Your machine seems to be... special? Is that the same machine you filed bug 581510 for?

Comment 3

[Wayne Mery (:wsmwk)]

yes, same machine

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

What kind of machine is that? How many RAM does it have?

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

How much, not how many. Sorry.

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to Tim Taubert [:ttaubert] from comment #4)
> What kind of machine is that? How many RAM does it have?

D531 Dell Lattitude. 3GB ram.

But the "out of memory" warning appears to be related to some issue internal to firefox, not real memory and not virtual memory (errors occur well below 2GB process limit)

nb. bug 581510 comment 20, bug 581510 comment 24, Bug 767343 comment 10

Comment 7

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

If you can reproduce this bug, could you send us the offending sessionstore.js? Warning: this file may contain private information, so you might wish to say "no".

Comment 8

[Wayne Mery (:wsmwk)]

sent.
Note, I did not attempt to retest with that sessionstore, with a current build.
Also, I have multiple sessionstore.js files with different issues

Comment 9

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

I don't know if this is the problem, but your file has several strings that are ~ 32kb. This should not be an issue, but that's probably a symptom of something weird.

windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[2].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[0]._closedTabs[0].state.entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[0]._closedTabs[1].state.entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[13].tabs[0].storage.https://bugzilla.mozilla.org.History.store (302293 bytes)

windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[2].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[0]._closedTabs[0].state.entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[13].tabs[0].storage.https://bugzilla.mozilla.org.History.store (bytes 302293)

windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[2].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[0]._closedTabs[1].state.entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[13].tabs[0].storage.https://bugzilla.mozilla.org.History.store (302293 bytes)

windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[2].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[0].tabs[0].entries[0].formdata.id.sessionData.windows[1].tabs[0].entries[0].formdata.id.sessionData.windows[13].tabs[0].storage.https://bugzilla.mozilla.org.History.store (302293 bytes)

Comment 10

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

Attachment: List of strings > 1kb

Comment 11

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

Attachment: Extraction script

Comment 12

[TheRave]

Checked my sessionstore with your python script and decided to investigated the bigest entry and the end of result.

This is a tab with a google search page. This tab contains 7 page changes (viewable due long press backwards button) in the history of this tab.

Decided to dublicate the tab (TMP function)and got the tabs[75] entry at the end of py result as following:

/QUOTE
this is only the end of the py result list...
.windows[0].tabs[154].storage.https://www.google.de.web-mhepUgU-30Fo3XsgakmYD4AQ ( 281045 bytes)
.windows[0].tabs[155].storage.https://www.google.de.web-mhepUgU-30Fo3XsgakmYD4AQ ( 281045 bytes)
.windows[0].tabs[74].storage.https://www.google.de.web::sbav=on.2,or.r_qf.&bpcl=38625945&fp=b9e9a7fb3d75b9c8&hl=de&newwindow=1&q=abdeckkappen kunststoff&rls=org.mozilla:de-DE:unofficial&safe=off&sei=aj_LUfVghcK0Bt72gPAN&tbm=isch&um=1 ( 337858 bytes)
.windows[0].tabs[75].storage.https://www.google.de.web::sbav=on.2,or.r_qf.&bpcl=38625945&fp=b9e9a7fb3d75b9c8&hl=de&newwindow=1&q=abdeckkappen kunststoff&rls=org.mozilla:de-DE:unofficial&safe=off&sei=aj_LUfVghcK0Bt72gPAN&tbm=isch&um=1 ( 337858 bytes)
/UNQUOTE

As next e tried to produce a new history entry due initiating a change in the search parameter in google on this tab, closed fx to save sessionstore and restart.

Result: last change of search on google was not stored in sessionstore (related to this tab) and fx started with the page before change...

There is definitely a problem with the session parameter of this tab and it should be investigated, why the tab is not useable for storing additional page changes. 

Have not investigated the other google tabs. But maybe it would be interesting why the google tabs have so high values of bytes.

Comment 13

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

Google tabs are known to store lots of DOMStorage and never garbage-collect it. Bug 952998 has improved the situation but if we need to further change the behavior, this will be part of bug 711465.

Comment 14

[TheRave]

I have isolated the tab by closing all other tabs.

Result was sessionstore file size shrinked from 7MB to 590KB. But this file is still to big. Checked the file and found out there was a lot of Tabgroupmanager entries for other web pages. Remarkable, because i see only one tab! Installed about:sessionstore extension. There was only 10 closed tabs in the session. Deleted them and got new file size 510KB. Still a lot of TGM stored pages.

But also interesting after tab isolating to one tab by closing all other tabs, fx was able to store new history entries related to this tab! So something other seems to be wrong in the initial sessionstore file. (additionally to the TGM related unvisible entries in the file)


/QUOTE
.windows[0].tabs[0].storage.https://www.google.de.web::sbav=on.2,or.r_qf.&bpcl=38625945&fp=4d68c78a6062b547&hl=de&newwindow=1&q=abdeckkappen kunststoff&rls=org.mozilla:de-DE:unofficial&safe=off&sei=aj_LUfVghcK0Bt72gPAN&tbm=isch&um=1 ( 366708 bytes)
.windows[0].tabs[0].storage.https://www.google.de.web::sbav=on.2,or.r_qf.&fp=4d68c78a6062b547&hl=de&newwindow=1&q=abdeckkappen kunststoff black&rls=org.mozilla:de-DE:unofficial&safe=off&tbm=isch&um=1 ( 436479 bytes)
/UNQUOTE

Conclusion: Will save all my open tabs as bookmarks and import them to a clean profile to get a clean sessionstore file, to get rid off the blind entries.

Comment 15

[Timea Cernea [:tbabos][inactive]]

Hey Wayne,
I believe there is a very low chance that you could retest this, given it was 7-8 years ago and you may also not have the same device. However, if this is not actionable anymore it is better if we close it and submit a new bug in the future if it happens again.

Comment 16

[Wayne Mery (:wsmwk)]

Thanks for asking. I haven't seen the issue in recent years, and I would expect this code to have changed. And I have even more tabs open now, over 1,000, than I did then.