sessionstore stopped updating almost 24 hours ago according to windows explorer, which means i lost some windows+tabs on firefox restart. see screen shot. I have some of the profile folders saved Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100531 Minefield/3.7a5pre

seen again. later in night I see that updates stoped @ 5:35pm sessionstore.js - exactly 3hr after the prior startup.

seen again. It's 4:28pm. 29MB sessionstore is dated 1:28pm :( only two addons changed in last few weeks afaict: FF sync (but it's disabled) compatibility reporter In error console I find, from some unknown time Error: out of memory Source File: file:///C:/Program%20Files/mozilla.org/MF%203.7%20b3%2020100723/components/nsSessionStore.js Line: 2869 Error: XULApp.Application.extensions is undefined Source File: resource://jetpack/modules/setup.js Line: 121 Error: redeclaration of const nsIWebNavigation Source File: chrome://browser/content/browser.js Line: 8 Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.clearUserPref]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://dotnetassistant/content/bootstrap.js :: BootStrapDotNetAsssitantExtension :: line 52" data: no] Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/browser.xml :: :: line 647" data: no] Source File: chrome://global/content/bindings/browser.xml Line: 653 Error: mContainer._viewer is undefined Source File: chrome://incrediblebookmarks/content/overlay.js Line: 215 ... Error: out of memory Source File: file:///C:/Program%20Files/mozilla.org/MF%203.7%20b3%2020100723/components/nsSessionStore.js Line: 2869 Error: out of memory Source File: file:///C:/Program%20Files/mozilla.org/MF%203.7%20b3%2020100723/components/nsSessionStore.js Line: 2869 etc

error continues, even though I've closed all windows except the prior session restore tab, so it looks like there is no way to get out of this "OOM" problem. I saved sesionstore.js Error: out of memory Source File: file:///C:/Program%20Files/mozilla.org/MF%203.7%20b3%2020100723/components/nsSessionStore.js Line: 2869 xref: bug 432924 I can't a list of extensions from NTT Mozilla/5.0 (Windows; Windows NT 6.0; rv:2.0b3pre) Gecko/20100723 Minefield/4.0b3pre

update ... before firefox crashed, as it tends to do at this stage, working set memory finally fell low enough to resolve the OOM. I had closed 17 windows and approx 160 tabs, leaving only the restore session tab of the prior session. And the sessionstore.js updated. it is now is now 11MB instead of 29MB. firefox working set dropped by 250MB (to 520MB), and GDI objects dropped by 4k (from 6k) per windows task manager. I'm back in business. Not sure what direction yet to take this, except part of the fix might be to inform the user the user that sessionstore had stopped being saved.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9pre) Gecko/20100809 Namoroka/3.6.9pre sessionstore.js 84MB fbs.onError (-1) with this.showStackTrace=true and this.breakOnErrors=true kind=undefined msg=out of memory@file:///C:/mozilla/ff3.6/download/firefox-3.6.4pre.en-US.win32/firefox/components/nsSessionStore.js:2855.0 2855: let jsonString = JSON.stringify(aJSObject);

it would also be nice if some user-facing message were provided when OOM occurs, or nears. Error Console doesn't cut it.

84MB file zipped to 109kb

there may be another behavior associated with this state which I haven't yet fully investigated ... fill in some bugzilla fields like keyword, and whiteboard, add a cc which won't resolve to a valid bugmail address, then "Save Changes which brings up the bugzilla error screen, then "Go back one page" ... the previously filled fields are blank

(In reply to comment #6) > it would also be nice if some user-facing message were provided when OOM > occurs, or nears. Error Console doesn't cut it. I did not get any Error Console message. All I got was a long pause. I saw the message only because I have Chromebug printing results from jsd.onErrors. The reason is that line 1165 of browser.js catches the error and drops it.

Sounds like a duplicate of bug 467409.

Wayne, my version of this bug is almost certainly a duplicate of bug 467409. I'm moving over there.

(In reply to comment #11) > Wayne, my version of this bug is almost certainly a duplicate of bug 467409. > I'm moving over there. yeah. that sounds wise. My reason for filing this bug is more related to the lack of feedback that sessionstore.js is not being saved, than restore failing.

(In reply to comment #12) > My reason for filing this bug is more related to the > lack of feedback [now] that sessionstore.js is not being saved, than restore failing [later]. modifying summary along the above line of thought and comment 6. Hope this is the correct component. note bug 467409 is only one possible cause. The other is simply accumulating enough tabs during normal browsing, such that sessionstore eventually "runs out of memory". zpao, do you recall what the limit is on how much memory can be used? I knew at one point but I'm not finding it recorded in a bug report

(In reply to comment #13) > zpao, do you recall what the limit is on how much memory can be used? I knew at > one point but I'm not finding it recorded in a bug report I don't

(I'm now using firefox trunk, which seems to use about 10-20% more memory based on my first trunk startup of sessionstore.js) I saw this again yesterday at about 150 tabs and it affected the saving of sessionstore.js Today I seen the message at 83 tabs, which isn't many tabs :( :( I'm not sure if it affected saving of sessionstore.js.

(In reply to comment #15) > Today I seen the message at 83 tabs, which isn't many tabs :( :( > I'm not sure if it affected saving of sessionstore.js. No, but based on how you (ab)use about:sessionrestore, # of open tabs isn't going to matter. Just to double check, JJB mentioned in comment #5 that the error was coming from > 2855: let jsonString = JSON.stringify(aJSObject); Next time you get the error, can you look at the line that's giving you the error and see if it's also the JSON.stringify line

Someone using my Session Manager add-on is running into the same problem with Firefox 3.6.15: Wed, 16 Mar 2011 04:42:58 GMT: {[JavaScript Error: "out of memory" {file: "file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/components/nsSessionStore.js" line: 2855}]} {JS frame :: file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/components/nsSessionStore.js :: sss_toJSONString :: line 2855} Wed, 16 Mar 2011 04:42:58 GMT: {[JavaScript Error: "out of memory" {file: "file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/components/nsSessionStore.js" line: 2855}]} {JS frame :: file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/components/nsSessionStore.js :: sss_toJSONString :: line 2855} He got the errors trying to save sessions (call to getBrowserState), he said he managed to save a session with 77 windows open with 100 tabs (size of 23 MB). There should probably be some kind of limit on attempting to JSON.stringify since at some point it simply won't work. If I recall correctly, the stringify has a limit on the amount of memory it's allowed to use, but don't quote me on that.

Something needs to be done to mitigate this problem. Someone else filed a bug with Session Manager saying he couldn't save sessions in Firefox 4.0 and when I checked his logs for Session Manager, I saw the following: Wed, 13 Apr 2011 01:15:00 GMT: {Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsISessionStore.getBrowserState]} {JS frame :: file:///C:/Documents%20and%20Settings/johnr/Application%20Data/Mozilla/Firefox/Profiles/6q059pwg.default/extensions/%7B1280606b-2510-4fe0-97ef-9b5a22eafe30%7D/modules/session_manager.jsm :: anonymous :: line 4116} I also saw a few NS_ERROR_OUT_OF_MEMORY errors in my own code so I think it's related to this bug. At least I can't think of any reason why the getBrowserState API function would throw a NS_ERROR_FAILURE error He only had 8 windows open so this doesn't require a large number of windows to be open. I'm not sure how many saved tabs and closed windows he had though. It seems to me that if a JSON string is too large, that maybe, it should be broken up? Perhaps each window should get it's own JSON string (array of strings) or the closed windows could be in their own JSON string?

morac, somewhere in the last few months (late 2010? / panorama?) in the runup to FF 4 the number of tabs where this begins to happen for me dropped by about 1/4 to 1/3, such that now I can encounter it at say 120 tabs. Previously I didn't see this until in the 400-500 tab range.

This is still with us. In Aurora 7.0a2 (Win32), I'm seeing this error. Last sessionstore.js file was 28MB, and typical save-time memory spike is ~3x the file size, but the max private bytes is about 1.1GB with a base size of 993MB, and VSS is ~1.3GB - well under the 2GB limit. # of tabs to provoke it probably isn't the issue, it's the final sessionstore size. The data-per-tab varies wildly from a few K to 600K+ (Google is by far the worst offender - see another sessionstore bug for that). Perhaps what's happening is an allocation is being made for the sessionstore size (or some multiple of is) during json_stringify(), and due to VM fragmentation(?) or some other such it can't get that large an object. Just a guess. This happens to me every time I run after some period (hours?) Adding njn since he's been working memshrink and jemalloc lately; flagging for memshrink (though it's a spike not a held allocation). Error: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIScriptableUnicodeConverter.convertToInputStream]" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" location: "JS frame :: resource:///components/nsSessionStore.js :: sss_writeFile :: line 4104" data: no] Source File: resource:///components/nsSessionStore.js Line: 4104

We decided in today's meeting that this is a MemShrink bug, sorry.

Sorry, I meant: "this is *not* a MemShrink bug"

Please look into the cause of this issue! On several occasions while attempting to save a session using Session Manager, I have encountered the same exact error that Michael Kraft discusses: ---------- This operation failed due to a file access error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsISessionStore.getBrowserState] My Session Name.session JS frame :: file:///C:/Documents%20and%20Settings/Owner/Application%20Data/Mozilla/Firefox/Profiles/j5ulnurt.default/extensions/%7B1280606b-2510-4fe0-97ef-9b5a22eafe30%7D/modules/session_manager.jsm :: anonymous :: line 4116 ---------- ...and in the error console I receive several messages that state the following: Error: out of memory Source File: file:///c:/program%20files/mozilla%20firefox/components/nsSessionStore.js Line: 2855

Ok, I've looked into this issue a little more, and it appears that the message I received is a little misleading. As it turns out, it seems that error is not due to a "file access error" at all. It appears that the culprit might be corrupted session window data that causes calls to the built-in function nsISessionStore::getBrowserState (of the firefox SessionStore API) to unexpectedly fail.

(In reply to Alex from comment #24) > Ok, I've looked into this issue a little more, and it appears that the > message I received is a little misleading. As it turns out, it seems that > error is not due to a "file access error" at all. It appears that the > culprit might be corrupted session window data that causes calls to the > built-in function nsISessionStore::getBrowserState (of the firefox > SessionStore API) to unexpectedly fail. could create a patch for it?

I ran into this again today. not a huge number of tabs open - maybe 50? But I had *closed* and opened and closed a lot of tabs in that session in the period of a few hours. I'm not certain whether I did a "restore" of a session before the error message - because I didn't see it until some hours after it was logged. But I know I did a restore or two after the message. I discovered the error because a much later (nested) session restore attempt failed after clicking "restore". sessionstore.js file is only about 6mb I captured the about:memory screens. Tried "minimize memory usage" but it didn't help.

I've had some cases lately of OOM (then eventually crash with empty stack) with smaller sizes of sessionrestore.js - in the 6-10MB range.

I have been getting many crashes since updating to Firefox 17 (linux), all at about 2.5G VM, always at amazon.com Each tab starts at up to 6M JS compartment, but eventually most use 25M for the JS according to about:memory. (0 tabs = 83M RAM used w. 3 addons: Tab counter, Session Manager, Toolbar buttons. 21 new amazon.com tabs = 580M physical RAM used. ) Total memory use seems to climb gradually when idle with 50+ tabs open. CPU stays pegged at 100% if over 50 tabs are loaded. Restarting after the crash, sometimes most of the tabs are missing, but more often they behave strangely, such as pages with no tabs. Once the toolbar I added was gone. Session Manager usually will not save a recovered session or any part of it. I use tree style tabs on some profiles, and it shows trees with no tabs and other bizarre things. I saved the about:memory page and its (very long) verbose page once when close to 2.5G VM, but they have nothing in them - 1k files with an empty box. One had a warning about a negative memory total. My sessionstore.js file is usually .5-1M. (This maybe should be a new bug? not a large .js)

(In reply to Wayne Mery (:wsmwk) from comment #27) > I've had some cases lately of OOM (then eventually crash with empty stack) > with smaller sizes of sessionrestore.js - in the 6-10MB range. still seeing this. something is really wrong here if in-memory session data can't handle 150 tabs, though I don't rule out complications from addons. Perhaps related, I recently filed memchaser bug 836284 because there are huge GC fields. Adding my crash info here in case it might help anyone who sees the same thing typical crash report bp-bp-111d2fa4-88e8-40ce-af21-d14662130202 [@ EMPTY: no crashing thread identified; corrupt dump ] example of recent crash vista laptop nightly 21.0a1 (2013-02-01) 1,683,998k peak work set per taskmgr sessionstore.js only 2MB approximately 150 tabs - 100 bugzilla tabs - 10 crash-stats tabs - 10 getsatisfaction tabs - 10 developer.mozilla.org - ~20 other tabs - no social crap like facebook from windbg ForgetSkippable 14 times before CC, min: 4 ms, max: 10 ms, avg: 6 ms, total: 84 ms, sync: 0 ms, removed: 17556 [JavaScript Error: "out of memory" {file: "resource:///modules/sessionstore/SessionStore.jsm" line: 4155}] [JavaScript Warning: "Use of attributes' specified attribute is deprecated. It always returns true." {file: "https://crash-stats.mozilla.com/js/jquery/jquery-1.6.4.min.js" line: 2}] [JavaScript Error: "out of memory" {file: "resource:///modules/sessionstore/SessionStore.jsm" line: 4155}] [JavaScript Error: "TelemetryStopwatch: key "FX_SESSION_RESTORE_SERIALIZE_DATA_MS" was already initialized" {file: "resource://gre/modules/TelemetryStopwatch.jsm" line: 53}] [JavaScript Error: "out of memory" {file: "resource:///modules/sessionstore/SessionStore.jsm" line: 4155}] [JavaScript Warning: "Unknown property '-moz-box-shadow'. Declaration dropped." {file: "https://crash-stats.mozilla.com/css/signature_summary.css" line: 13 column: 20 source: " -moz-box-shadow: 5px 5px 6px #ccc;"}] [JavaScript Warning: "Unknown property '-moz-border-radius'. Declaration dropped." {file: "https://crash-stats.mozilla.com/css/signature_summary.css" line: 54 column: 23 source: " -moz-border-radius: 6px;"}] eax=00000000 ebx=41273510 ecx=67ec3896 edx=00000003 esi=67e71ec6 edi=67ec379c eip=7247198a esp=0019c3b0 ebp=0019c3b8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00200202 *** WARNING: Unable to verify checksum for C:\Program Files\mozilla.org\FF 21.0a1 2012-02-02\mozalloc.dll mozalloc!mozalloc_abort+0x2d: 7247198a cc int 3 0:000> ~* kp;!analyze -f;lm . 0 Id: 1da0.1be0 Suspend: 1 Teb: 7ffde000 Unfrozen ChildEBP RetAddr 0019c3b8 72471a04 mozalloc!mozalloc_abort(char * msg = 0x724720ec "out of memory")+0x2d [e:\builds\moz2_slave\m-cen-w32-ntly\build\memory\mozalloc\mozalloc_abort.cpp @ 30] 0019c3c4 724710bf mozalloc!mozalloc_handle_oom(unsigned int size = 0x18762c)+0x1f [e:\builds\moz2_slave\m-cen-w32-ntly\build\memory\mozalloc\mozalloc_oom.cpp @ 27] *** WARNING: Unable to verify checksum for C:\Program Files\mozilla.org\FF 21.0a1 2012-02-02\gkmedias.dll 0019c3d4 60f0aec7 mozalloc!moz_xmalloc(unsigned int size = 0x18762c)+0x1f [e:\builds\moz2_slave\m-cen-w32-ntly\build\memory\mozalloc\mozalloc.cpp @ 56] *** WARNING: Unable to verify checksum for C:\Program Files\mozilla.org\FF 21.0a1 2012-02-02\xul.dll 0019c438 59f0c7aa gkmedias!mozilla::gfx::AlphaBoxBlur::Blur(void)+0xf6 [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\2d\blur.cpp @ 525] 0019c4c4 59f0c8b0 xul!gfxAlphaBoxBlur::Paint(class gfxContext * aDestinationCtx = 0x00000000, struct gfxPoint * offset = 0x0019c4d8)+0x1f [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\thebes\gfxblur.cpp @ 88] 0019c520 59ec3154 xul!nsContextBoxBlur::DoPaint(void)+0x48 [e:\builds\moz2_slave\m-cen-w32-ntly\build\layout\base\nscssrendering.cpp @ 4803] 0019c6fc 59ef3349 xul!nsCSSRendering::PaintBoxShadowOuter(class nsPresContext * aPresContext = 0x67ec3896, class nsRenderingContext * aRenderingContext = 0x30d3e480, class nsIFrame * aForFrame = 0x319d8320, struct nsRect * aFrameArea = 0x00000003, struct nsRect * aDirtyRect = 0x0019c750)+0x48d [e:\builds\moz2_slave\m-cen-w32-ntly\build\layout\base\nscssrendering.cpp @ 1353] 0019c7f0 59e47569 xul!nsDisplayBoxShadowOuter::Paint(class nsDisplayListBuilder * aBuilder = 0x0019dfb8, class nsRenderingContext * aCtx = 0x30d3e480)+0xd1 [e:\builds\moz2_slave\m-cen-w32-ntly\build\layout\base\nsdisplaylist.cpp @ 2444] 0019cc0c 59db859e xul!mozilla::FrameLayerBuilder::DrawThebesLayer(class mozilla::layers::ThebesLayer * aLayer = 0x34546400, class gfxContext * aContext = 0x30094940, class nsIntRegion * aRegionToDraw = 0x0019cd24, class nsIntRegion * aRegionToInvalidate = 0x0019cdec, void * aCallbackData = 0x0019dfb8)+0x1559 [e:\builds\moz2_slave\m-cen-w32-ntly\build\layout\base\framelayerbuilder.cpp @ 3345] 0019cc94 59e6529d xul!mozilla::layers::BasicShadowableThebesLayer::PaintBuffer(class gfxContext * aContext = 0x30094940, class nsIntRegion * aRegionToDraw = 0x0019cdbc, class nsIntRegion * aExtendedRegionToDraw = 0x0019cd24, class nsIntRegion * aRegionToInvalidate = 0x0019cdec, bool aDidSelfCopy = false, <function> * aCallback = 0x59e46010, void * aCallbackData = 0x0019dfb8)+0x2e [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\layers\basic\basicthebeslayer.cpp @ 403] 0019ccb4 59e4600f xul!nsRegion::Copy(class nsRegion * aRegion = 0x0019dfb8)+0x4d [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\src\nsregion.cpp @ 579] 0019ce2c 59e407c9 xul!nsRegion::SetToElements+0xff 0019ceb0 59e60b9f xul!nsRegion::SubRect(struct nsRegion::nsRectFast * aRect = <Memory access error>, class nsRegion * aResult = <Memory access error>, class nsRegion * aCompleted = <Memory access error>)+0x369 [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\src\nsregion.cpp @ 1244] 0019cf04 0019dfb8 xul!mozilla::layers::ContainerLayer::SortChildrenBy3DZOrder(class nsTArray<mozilla::layers::Layer *> * aArray = 0x0019d2a8)+0x7f [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\layers\layers.cpp @ 837] WARNING: Frame IP not in any known module. Following frames may be wrong. 0019cf30 60ef5d34 0x19dfb8 ... 05bbf8b8 6dfc5e61 ssl3!ssl_SecureSend(struct sslSocketStr * ss = <Memory access error>, unsigned char * buf = <Memory access error>, int len = <Memory access error>, int flags = <Memory access error>)+0x134 [e:\builds\moz2_slave\m-cen-w32-ntly\build\security\nss\lib\ssl\sslsecur.c @ 1209] Gotta try something, so I'm disabling telemetry and health report.

I have the same error. Still not fixed in Firefox 24.

Got this error: (Firefox 25.0.1, Session Manager 0.8.0.8) This operation failed due to a file access error: Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIScriptableUnicodeConverter.convertToInputStream] backup.session JS frame :: chrome://sessionmanager/content/modules/session_file_io.jsm :: <TOP_LEVEL> :: line 1807 JS frame :: chrome://sessionmanager/content/modules/session_file_io.jsm :: <TOP_LEVEL> :: line 1783 JS frame :: chrome://sessionmanager/content/modules/session_file_io.jsm :: <TOP_LEVEL> :: line 1343 JS frame :: chrome://sessionmanager/content/modules/session_file_io.jsm :: <TOP_LEVEL> :: line 157 JS frame :: chrome://sessionmanager/content/modules/session_manager.jsm :: <TOP_LEVEL> :: line 372 native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0

(In reply to Webmaster33 from comment #31) > (Firefox 25.0.1, Session Manager 0.8.0.8) > JS frame :: chrome://sessionmanager/content/modules/session_file_io.jsm That's a similar failure but is caused by the SessionManager add-on. This has nothing to do with core Firefox code.

(In reply to Tim Taubert [:ttaubert] from comment #32) > (In reply to Webmaster33 from comment #31) > > (Firefox 25.0.1, Session Manager 0.8.0.8) > > JS frame :: chrome://sessionmanager/content/modules/session_file_io.jsm > > That's a similar failure but is caused by the SessionManager add-on. This > has nothing to do with core Firefox code. Thanks, reported the bug to SessionManager developer.

Has anyone encountered this error during the past year? I see that bug 962916 has been marked as a possible duplicate, but I'm not sure it's the same issue.

I'm not sure if it's exactly the same error, but I've had a number of reports of people getting an "out of memory" error in Session Manager when it calls the SessionStore getWindowState API call. Most have a large amount of open tabs and/or closed windows/tabs, but are not anywhere near their system's memory limits.

I wonder if it's really "out of memory". Some C++ operations that indicate a failure but forget to throw an error are reported as out of memory. Michael, by any chance, do you have a JS stack trace? As a side-note, we are working on a new API for reading Session State that doesn't go through JSON. Depending on the underlying issue here, this might fix it.

Unfortunately I catch and re-throw errors from calls to the API so all my stack traces stop at the call to getBrowserState so all I can see is the error 'out of memory' (NS_ERROR_XPC_JS_THREW_STRING). I can add a log call to log the original stack trace, which I probably should have done originally, but most people don't include the logs anyway which is why I display a popup. When I originally looked into this the problem was caused by doing string manipulations on the JSON string since those seem to use a lot more memory than the string itself is using. That was a long time ago and a lot has changed. Though if JSON is completely removed, I expect the problem will go away.

Recaping and expanding on some of my previous comments. For me: - not OOM in my opinion, but ... - could be caused virtual memory fragmentation, which is a current focus of developers and has had one or two fixes in the past couple years - I've not seen it in a long time (nor do I want to). But ... - in at least half a year Firefox has not been able to sustain, reach the number of tabs I previously loaded, therefore I wouldn't expect to encounter it - Perhaps mitigated by bug 467409? But, I have seen and reported it since that landed - n.b. comment 5, comment 26, comment 27 i.e. not large numbers of tabs - I have no reason to believe it is gone. But a code change might have killed it or made it less likely. And in any event none of the above gets to the point that if the problem does occur that *the user is not warned*, which the point of this bug on a side note, is bug 464350 still relevant?

I use Tabgroubsmanager with a lot of groups and tabs of course. I have seen this error very often if i use the Fx over several days without restarting. Then i found a corrupt tab, where it was not able to store additional tab page changes in the history of the back button. After restart of Fx it was always opened a defined page and never the page which was open as i closed the Fx. There was also no error message. Closed all my groups and tabs without the defective tab and reduced sessionstore from 7MB to 590KB for this one tab. Fx shows the history for this tab only some 7 page changes (some google searches), but in the 500KB sessionstore.js was a lot more of pages which was not displayed in history of back button and there was only one tab! Last but not least decided to save all my groups to bookmarks, delete my sessionstore.js file and open my bookmarks to get rid of the blind entries in sessionstore. Made some comments in Bug 90321 regarding this. The way to fix the defective tab was also the way to get rid of the out of memory error. Since three weeks i have not seen the error. A little bit short timeframe but until now it seems to work.

^^ 903621

(In reply to David Rajchenbach Teller [:Yoric] from comment #35) > Has anyone encountered this error during the past year? I see that bug > 962916 has been marked as a possible duplicate, but I'm not sure it's the > same issue. I have. I have only seen this error console message once before but that is because I do not generally look in it. After I saw it, I googled for it and voted for this bug. I am regularly affected by the symptoms described in bug #962916 and I have had several crashes (5 on Firefox 30.0 since I installed it on 18th June and I have been away nearly a week) with signatures like: Firefox 30.0 Crash Report [@ OOM | large | NS_ABORT_OOM(unsigned int) | XPCConvert::JSData2Native(void*, JS::Handle<JS::Value>, nsXPTType const&, bool, nsID const*, tag_nsresult*) ] In addition, I just opened the Error Console and lo and behold I am affected by this issue right now! Timestamp: 03/07/2014 11:15:07 Error: [Exception... "out of memory'out of memory' when calling method: [nsITimerCallback::notify]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] Needless to say, I have RAM available (although less than what I would like). Firefox is using around 1 GB Working Set Memory, and it is about this level that I normally kill it anyway (because it becomes sluggish on this computer) and restore my session. Sometimes, it crashes before I kill it. firefox.exe right now: Memory - Working Set: 1,078,080 K, Peak Working Set: 1,371,040 K, Commit Size: 1,306,000 K (changing all the time), Paged Pool: 467 K, NP Pool: 104 K, GDI Objects 1,785. Total Physical Memory usage: 78% of 3964 MB, Cached 1074 MB, Free 54 MB O/S Windows Vista SP2. Free memory from Task Manager did drop to 0 MB for a time before Windows released some of the Cached memory, but this is normal for Windows (and Linux behaves similarly) in that it uses free memory as a cache, so, really I had over 1 GB Available RAM (and 'Available RAM' is also displayed I think on Windows 7).

Seb, what makes you think it's the same bug? Does this prevent Session Restore from being written?

(In reply to David Rajchenbach Teller [:Yoric] from comment #43) > Seb, what makes you think it's the same bug? Does this prevent Session > Restore from being written? Well, you could argue there are two (or more) bugs: 1. That sessionstore.js stops updating due to this exception (or other exceptions). 2. That a warning is not displayed to the user that their session is no longer being saved. I think the point of this bug report (at least according to the title of it) is point 2. And I think that is the more serious issue. Yes, the problems should be fixed so that sessionstore keeps updating, and that may obviate the need for point 2 - but at some point there are new problems bound to be introduced that will break it again. Hence why a warning should be displayed to the user (point 2) IMHO. In terms of bug #962916, it is vague in terms of technical details, but it is exactly how most users will see the problem. The timestamp on my current sessionstore.js is 26/06/14 20:12 (and the size is 15,474 KB), so, Yes, my sessionstore.js is no longer being updated (given that I am using that session right now to type this message and also used it last Friday before not using my computer for some days).

Copied from the Messages tab of my Error Console: 1404387600036 Sync.Engine.Tabs WARN Error creating record: out of memory'out of memory' when calling method: [nsISessionStore::getBrowserState] Stack trace: getAllTabs()@resource://gre/modules/services-sync/engines/tabs.js:104 < createRecord()@resource://gre/modules/services-sync/engines/tabs.js:141 < SyncEngine.prototype._createRecord()@resource://services-sync/engines.js:817 < SyncEngine.prototype._uploadOutgoing()@resource://services-sync/engines.js:1410 < SyncEngine.prototype._sync()@resource://services-sync/engines.js:1481 < WrappedNotify()@resource://services-sync/util.js:143 < Engine.prototype.sync()@resource://services-sync/engines.js:655 < _syncEngine()@resource://services-sync/stages/enginesync.js:199 < sync()@resource://services-sync/stages/enginesync.js:149 < onNotify()@resource://gre/modules/services-sync/service.js:1255 < WrappedNotify()@resource://services-sync/util.js:143 < WrappedLock()@resource://services-sync/util.js:98 < _lockedSync()@resource://gre/modules/services-sync/service.js:1249 < sync/<()@resource://gre/modules/services-sync/service.js:1240 < WrappedCatch()@resource://services-sync/util.js:72 < sync()@resource://gre/modules/services-sync/service.js:1228 < <file:unknown> I also get: Timestamp: 03/07/2014 12:50:32 Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_SERIALIZE_DATA_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53 Timestamp: 03/07/2014 12:50:32 Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_SERIALIZE_DATA_LONGEST_OP_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53 Timestamp: 03/07/2014 12:50:32 Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_WRITE_STATE_LONGEST_OP_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53 Immediately prior to some (but not all) of the: Timestamp: 03/07/2014 12:50:32 Error: [Exception... "out of memory'out of memory' when calling method: [nsITimerCallback::notify]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no]

While there's already clear evidence here, I'll note that a WinXP machine I recently retired was continuing to have lost history when it OOMed or was near it. (Aurora 31 and 32). I'll watch for it on other machines (that one due to XP mem limits was more likely to OOM) - but normally I don't notice until I crash/restart, and then it's too late to check the console.

(In reply to Randell Jesup [:jesup] from comment #46) > ... but normally I don't notice > until I crash/restart, and then it's too late to check the console. Exactly the problem most of us are getting. I suggest a Firefox error.log file that the Error Console writes to. If we don't want it to get too big, it could be a circular log file limited to a certain size - or if we don't mind too much, it could be saved to %LOCALAPPDATA% (at least on Windows) - or it could be deleted every time the user updates / upgrades their Firefox (which is mostly fairly often).

In about memory i have this measured in failure case: 1,331.50 MB ── private 1,196.79 MB ── resident 1,891.55 MB ── vsize 2.88 MB ── vsize-max-contiguous

For what it is worth, I have literally been dealing with this issue for years now. I run a lot of windows with a lot if tabs. It includes many Google searches and Google Maps windows which i suspect are responsible for Firefox running out of memory even though the system has more memory. I got my Firefox running better by installing FlashBlocker and though I'd take another stab at getting the memory/ recovery.js showed the time stamp of the browser start time and was not updating. I started by clearing out any tabs and windows that I could live without. I had a recursed sessionstore I then restored. Started clearing out more tabs. Browser started acting strange, not displaying the contents of windows. Restarted Firefox hoping it would create a new sessionstroe.js based on the current tabes, but most if no all changes from the last startup were lost. Started over and did the same steps but got more aggressive about closing tabs. Browser remained stable. after some cleanup I started hitting "forget closed tabs" and "forget closed windows" in the sessionstore add-on. I t generated this error: uncaught exception: out of memory <unknown> NS_ERROR_XPC_JS_THREW_STRING: out of memory'out of memory' when calling method: [nsISessionStore::getBrowserState] aboutsessionstore.js:12:0 After clearing gout some more tabs (ones I'd rather not have closed) I started getting this error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsISessionStore.getBrowserState] If I reload the about:sessionstore windows, I get the same error. Still recovery.js was not being updated. The about:sessionstore tab is not displaying any data so it is really hard to find what tabs I can close. I am down to 52 windows at the moment. Down to 50 windows and Firefox is starting to not display things again, so I'm going to post this as-is before I loose it.

Check in about:memory vsize-max-contiguous and observe what is happening with this value.

(In reply to TheRave from comment #50) > Check in about:memory vsize-max-contiguous and observe what is happening > with this value. While the browser is still working I'm seeing reading like 384MB, 546MB, 328MB and 292Mb. Today the browser started having trouble displaying windows. At that point I checked and it was down to just 8.18MBB. Tried to close some windows but it was too late, the browser crashed shortly thereafter. As usual the lase hour or two of changes in windows and tabs did not get saved.

We need a kind of defrag to recycle the memory...

David, can you please help in putting this on someones TODO?

Memory management falls under njn's realm.

Before last two crashes, once browser started having display issues, clicking "measure" in about:memory crashed the browser. Today's crash, vsize-max-contiguous was 3.65 MB. Restarting browser, it crashed before shutting down cleanly. After the restart vsize-max-contiguous is at 286.88 . Tab changes lost during all crashes.