Open Bug 1691498 Opened 4 years ago Updated 2 years ago

Could not write session state file Error: TypeError: cannot use 'in' operator to search for "toMsg" in "out of memory"

Categories

(Firefox :: Session Restore, defect)

Firefox 84
Unspecified
Windows
defect

Tracking

()

People

(Reporter: atommaster, Unassigned)

Details

Attachments

(7 files)

Attached image ram2.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

more than 1000 tabs, all background, active 2-3 pieces, after 10-15-20 minutes, the session files in the sessionstore-backups folder stop changing (they must be every 15 seconds), then I work in the browser without problems for 4-5 hours, close it, and when I open it, not the last tabs are opened, but outdated by 4-5 hours, exactly when the files in the sessionstore-backups folder stop changing, the console writes an error - Could not write session state file Error: TypeError: cannot use 'in' operator to search for "toMsg" in "out of memory" .
Windows 7 x32, 3gb ram in me system.
Could not write session state file Error: TypeError: cannot use 'in' operator to search for "toMsg" in "out of memory"
postMessage resource://gre/modules/PromiseWorker.jsm:349
post resource://gre/modules/PromiseWorker.jsm:388
_postToWorker resource:///modules/sessionstore/SessionFile.jsm:411
write resource:///modules/sessionstore/SessionFile.jsm:448
write resource:///modules/sessionstore/SessionFile.jsm:75
_writeState resource:///modules/sessionstore/SessionSaver.jsm:360
_saveState resource:///modules/sessionstore/SessionSaver.jsm:294
_saveStateAsync resource:///modules/sessionstore/SessionSaver.jsm:344
saveStateAsyncWhenIdle resource:///modules/sessionstore/SessionSaver.jsm:191
callback resource://gre/modules/Timer.jsm:127
ChromeUtils::IdleDispatch handlerrequestIdleCallback resource://gre/modules/Timer.jsm:131
_timeoutID resource:///modules/sessionstore/SessionSaver.jsm:194
notify resource://gre/modules/Timer.jsm:62
postMessage@resource://gre/modules/PromiseWorker.jsm:349:17
Async
post@resource://gre/modules/PromiseWorker.jsm:388:17
_postToWorker@resource:///modules/sessionstore/SessionFile.jsm:411:26
asyncwrite@resource:///modules/sessionstore/SessionFile.jsm:448:24
write@resource:///modules/sessionstore/SessionFile.jsm:75:32
_writeState@resource:///modules/sessionstore/SessionSaver.jsm:360:24
_saveState@resource:///modules/sessionstore/SessionSaver.jsm:294:17
_saveStateAsync@resource:///modules/sessionstore/SessionSaver.jsm:344:10
saveStateAsyncWhenIdle@resource:///modules/sessionstore/SessionSaver.jsm:191:14
callback@resource://gre/modules/Timer.jsm:127:16
ChromeUtils::IdleDispatch handler
requestIdleCallback@resource://gre/modules/Timer.jsm:131:15
runDelayed/this._timeoutID<@resource:///modules/sessionstore/SessionSaver.jsm:194:30
notify@resource://gre/modules/Timer.jsm:62:17

other screens:
https://ibb.co/s5dFQvT
https://ibb.co/xS0kHBb
https://ibb.co/L8XwD4G

Actual results:

the session when exiting the browser is saved not the last but outdated, not fresh

Expected results:

when you open the browser again, the tabs that were before closing the browser should open, and not outdated by 4-5 hours or more

Attached image session.jpg
Attached image ram.jpg
Attached image ram3.jpg

The Bugbug bot thinks this bug should belong to the 'Firefox::Search' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Search
Component: Search → Session Restore

I can also add a second bug, if I try to clean up - "Delete recent history ...", with such parameters as in my screenshot, then when you restart the browser, all session backup files are deleted altogether !! the browser restarts empty, with one start tab, without my tabs, and one 1kb file "recovery.jsonlz4" appears in the "sessionstore-backups" folder, session files are lost forever, it is impossible to recover. Comrades, fix it !!

Attached image bug2.jpg
Attached image bug2_history.jpg

I'm having the same bug (Confirmed on nightly build id 20210227214359) with 64 bit windows 10. Have had issues with session store for months, but this is first time I've seen an error in console associated with it.
There doesn't appear to be a call stack associated with the throwing worker. Is there any way to see this in the worker?

If I open browser toolbox, and place breakpoints in write() frunction in resource:///modules/sessionstore/SessionWorker.js line 140,
I can see that it fails with out of memory on line 165 : let data = Encoder.encode(stateString);

If in console, while program paused on line 165, I can get string length it is:

stateString.length
715993463

Setting to new, as I think it's same bug despite being slightly different windows and x86 architectures.

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Windows

Fnally, the exception handling is broken when strings are thrown as exception in handleMessage() in PromiseWorker.js.
As it stands, should just return "out of memory" as error, but the wierd error is generated instead.
Or even better as some of the missing stack context around "out of memory"
This happens on line 184. Probably similar to bug 1083318.

Did some C++ debugging to find where this came from.
Summary:
It's hitting an internal size limit on strings that means a length of stateString of 715835524 would fail, but a length of 715826828 would not.

@Atom99: when the session store is failing, if you can add a breakpoint in the browser toolbox, at line 165 of SessionWorker.js, and then type stateString.length into the toolbox js command line, and report the value might be helpful. Will show if it's similar bug or not.

Details:
For me, it comes from the encode() function in TextEncodingBinding.cpp, where it calls ConvertJSValueToString().
Eventually reaches line 154 of nsTsubstring, and fails.
Turns out that nsTsubstring can only allocate arrays of up to 2147483638 bytes. The size ConvertJSValueToString() requests is just slighly too large. But I'm not clear how this size is derived from the size seen in stateString.length. Could this be a utf8 string, and length returns length in unicode chars, while nsTsubstring is dealing in actual bytes?

This is still a (very annoying) thing..
Also, bug 1590378 reported a similar error message along the lines. Maybe that could help with reproducing.

See Also: → 1764761
See Also: 1764761

A user on SUMO running Firefox 102esr reports that Firefox stops writing to recovery.jsonlz4 some time during the session (and fails to save an updated sessionstore.jsonlz4 file at shutdown). The Browser Console shows an "out of memory" error (attached), which appears to be the same issue discussed in this bug.

I suggested the user try to modify some preferences that control the size of session data (back-forward depth, max closed tabs, privacy_level). At this point, I don't have any feedback on those suggestions. See: session store recovery.jsonlz4 does not update frequently.

If it would be helpful to ask the user to undertake some debugging steps -- I'm not sure I can describe how to take the steps described in comments 8-10 -- let me know.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: