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

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

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?

yes, same machine

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

How much, not how many. Sorry.

(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

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

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

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)

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.

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.

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.