Closed Bug 1578224 Opened 5 years ago Closed 5 years ago

Crash in [@ OOM | small]

Categories

(Core :: Storage: localStorage & sessionStorage, defect)

69 Branch
x86_64
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: worcester12345, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-f4be7fcd-868c-4134-b71d-348860190902.

Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 mozglue.dll moz_xmalloc memory/mozalloc/cxxalloc.h:33
3 xul.dll mozilla::BufferList<InfallibleAllocPolicy>::WriteBytes mfbt/BufferList.h:410
4 xul.dll Pickle::WriteBytes ipc/chromium/src/base/pickle.cc:630
5 xul.dll mozilla::dom::PBackgroundStorageChild::SendAsyncAddItem ipc/ipdl/PBackgroundStorageChild.cpp:224
6 xul.dll nsresult mozilla::dom::StorageDBChild::AsyncAddItem dom/storage/StorageIPC.cpp:274
7 xul.dll nsresult mozilla::dom::LocalStorageCache::SetItem dom/storage/LocalStorageCache.cpp:390
8 xul.dll void mozilla::dom::LocalStorage::SetItem dom/storage/LocalStorage.cpp:120
9 xul.dll static bool mozilla::dom::Storage_Binding::setItem dom/bindings/StorageBinding.cpp:217

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 ID:20190827005903

Philipp, is there anything useful we can glean from this OOM report? I'm not sure I follow why we're OOM'ing when asking for just 4kb here.

Flags: needinfo?(madperson)

without any context about what happened around the time of the crash, i fear there's little to go on just based on this crash id. the system already seemed to be under high memory pressure at the time of the crash (System Memory Use Percentage: 92, Available Page File: 34.92 MB), so an OOM crash isn't surprising.
in general [@ OOM | small] crashes with mozilla::dom::PBackgroundStorageChild::SendAsyncAddItem on the stack seem to be relatively rare though...

Flags: needinfo?(madperson)

Meh, maybe the indexeddb people can do something with the stack if it's rare, otherwise I guess we can close incomplete.

Component: General → DOM: IndexedDB
Product: Firefox → Core

The crashing stack looks like it's something related to the old local storage implementation. Andrew, is it something we can help at this moment? Otherwise, maybe we can close incomplete.

Component: DOM: IndexedDB → DOM: Web Storage
Flags: needinfo?(bugmail)

Agreed that this is old LocalStorage. Agreed with comment 2 that this looks like an OOM that can't really be avoided at this point. Which isn't to say this couldn't be an "evil trap" scenario where there is a web page doing something sketchy that we could help mitigate the effects from... but it's impossible to know what's going on from just this crash.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(bugmail)
Resolution: --- → INCOMPLETE

Other programs will ask to "wait for the program", instead of crashing. Is this not something Mozilla can also do?

If I understand correctly, you're referring to the dialog that Windows, for example, shows when a program is unresponsive, providing an option to wait or terminate. In this case, the program is responsive, but the system is out of memory. The program can't make forward progress without the memory and does not have a way to attempt to reduce memory usage in the middle of normal execution, especially if the system doesn't have 4k of memory available or if the process has run out of address space. Normally I think that if the OS can make more memory available, it will pause the thread while it frees up memory.

That said, we have been putting a lot of effort to improve the memory usage of LocalStorage. In Firefox 70 (now on beta), we have a new LocalStorage implementation that improves LocalStorage related memory usage and we are actively working on further improving address space-usage issues for extremely large values stored by sites. If you want to try out the new implementation, you can flip the "dom.storage.next_gen" preference in about:config and see if that helps in general. (To put that in another way, we are no longer enhancing the LocalStorage code that triggered the crash in 69, so there's not really much room for improvement as it relates to this crash. However, if you experience similar issues on Firefox beta and can identify specific sites that trigger the problem, we would very much appreciate if you could file a new bug with the new information.)

OK, I'll buy that. Now on version Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0 ID:20190912160217 , so we'll see how that works going forward. Also helpful if Thunderbird can cut over to 64-bit as soon as possible.

See Also: → 1616720
Keywords: crash
Resolution: INCOMPLETE → WONTFIX
You need to log in before you can comment on or make changes to this bug.