1799313 - Excessive RAM consumption from structured-clone-holder objects

Status: RESOLVED DUPLICATE of bug 1769763

(WebExtensions :: General, defect, P2)

Description

[tck3ily7w]

Attachment: memory-report.json.gz

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0

I have only opened some pages and I have been browsing between them, and in the same way open and close others. Nothing specific, it has happened on different occasions and I came to think that perhaps it is because of the time using the browser, but the time between the times that it has happened do not agree

Whether I have multiple tabs open or not, whether I play videos or music, it just happens no matter what I do or not.

Actual results:

When I am using the browser, it happens that it begins to consume too much ram memory, leaving me with almost the amount consumed at 100%, leaving the browser frozen or simply giving the browser an error and being unable to use it for a few minutes.

It should be noted that when I check the task manager of the browser or the operating system, it shows that almost all the use of RAM is by the browser.

With difference that when I check the browser's task manager it says that the use is from the "Firefox" process, and seconds later the consumption drops considerably to what should be its normal

The use of ram by the browser has reached up to 8gb

Expected results:

I thought maybe it was because of some extension installed, or maybe the version of the browser in use, but I have already tried the existing versions from Beta to Nightly and the same thing has happened to me. I have also disabled hardware acceleration and nothing has changed

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alastor Wu [:alwu]]

From the report in the comment1, I can see 4,244.98 MB allocation in the main process for the structured-clone-holder. By contrast, opening a new Nightly without any tab opened uses around 300 MB. I'm not sure what that structured-clone-holder is, Nika, do you have any thought about this? or do you know how to debug this kind of memory issue in the main process?
Thank you so much.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

A StructuredCloneHolder is the type which holds onto structured clone payloads, storing them while at rest. That being said, it appears that "structured-clone-holder" in about:memory is actually a measurement of C++ StructuredCloneBlob instances, as the value is reported there (https://searchfox.org/mozilla-central/rev/185db4a5f794fa6afbbd446944bdeaf640ba7d72/dom/base/StructuredCloneBlob.cpp#224-226). These are JS controlled objects which internally hold a structured clone payload. In JS this type is known as StructuredCloneHolder (a bit confusing, unfortunately).

IIRC the most common use of these StructuredCloneHolder objects is by the WebExtension runtime, which uses them to pass around data between extensions and between processes. It seems possible that there's either some leak in the web extension code causing us to generate excessive amounts of these objects, or a specific extension which is somehow overloading us with persistent StructuredClone{Blob,Holder} instances.

Redirecting the needinfo to :kmag and :zombie who are more familiar with the WebExtension implementation, and might have an idea what could cause large numbers of StructuredCloneHolder objects to persist in the parent process.

(as a side note, perhaps it would be valuable to add some kind of description to StructuredClone{Blob,Holder} which could let us credit the sources of these individual objects more accurately in memory reports?).

Comment 4

[Kris Maglione [:kmag]]

I agree it would be good to add descriptions to StructuredCloneHolder objects to make it easier to find the source of these leaks. I'll write a patch for that.

This has come up before, and I wasn't able to find a reason the objects were being held alive so long, so I changed most of the consumers to release the data as soon as they knew it wouldn't need to be decoded again. I couldn't make that work for all uses, though, and I don't know which of them would be responsible for this leak.