1916236 - alerabat extension uses gigabytes of memory through StructuredCloneHolder in the extension process

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[dzyszla]

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

Steps to reproduce:

In about:processes the Extensions item show a large amount of RAM - over 6GB. Firefox can allocate all of free memory in system.
The memory will free only if I manually run GC or add/remove any extension.

In 115 ESR it's be self free if consume maximum 3GB.

Actual results:

System can crash, because no free memory left.

Expected results:

Fired garbage collector automatically if here is no free RAM left.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Rob Wu [:robwu]]

Could you capture a memory report at about:memory and share it here?

Comment 3

[dzyszla]

Attachment: Memory report

Here

Comment 4

[dzyszla]

Attachment: Another system memory report

Comment 5

[Rob Wu [:robwu]]

When I open the attached files in about:memory, I see the following entries under the extension process section. These entries are associated with this add-on that you have installed: https://addons.mozilla.org/en-US/firefox/addon/alerabat-kupony-kody-rabatowe/

If you remove or disable this extension, your performance issue will probably be resolved. Can you confirm whether this helps?

8,101,155,104 B (100.0%) -- explicit
├──7,997,614,000 B (98.72%) -- dom
│  ├──7,997,612,688 B (98.72%) -- structured-clone-holder
│  │  ├──7,995,831,712 B (98.70%) ── Messenger/{6c0839b6-2697-49ca-ac8c-8c65a8d9b7b9}/sendRuntimeMessage [935]

7,120,983,904 B (100.0%) -- explicit
├──6,727,745,088 B (94.48%) -- dom
│  ├──6,727,743,776 B (94.48%) -- structured-clone-holder
│  │  ├──6,709,203,808 B (94.22%) -- Messenger
│  │  │  ├──6,707,340,320 B (94.19%) ── {6c0839b6-2697-49ca-ac8c-8c65a8d9b7b9}/sendRuntimeMessage [2389]

Additional analysis:

• The StructuredCloneHolder is initialized at https://searchfox.org/mozilla-central/rev/aee7c3a0dbf33af0c4f6648f391db62b35895e50/toolkit/components/extensions/ExtensionChild.sys.mjs#343-352
• The extension (version 0.33.5 of https://addons.mozilla.org/en-US/firefox/addon/alerabat-kupony-kody-rabatowe/)'s background script calls tabs.sendMessage with a large object (a tabs.Tab type) as part of sending messages to content scripts. We should investigate whether the memory leaks are caused by the extension or by Firefox's extension framework.

Comment 6

[dzyszla]

I confirm (now tested on 128.2) that is probability source of the problems - after disable this, memory usage does not increase as much.

There are two questions that may help in the investigation:

1. Why in previously ESR Firefox not consume so large amount of RAM?
2. Why, after manually execute GC, memory usage drops down?

Thanks for your help so far! If you need anything, please feel free to contact me.

Comment 7

[Rob Wu [:robwu]]

(In reply to dzyszla from comment #6)

I confirm (now tested on 128.2) that is probability source of the problems - after disable this, memory usage does not increase as much.

There are two questions that may help in the investigation:

1. Why in previously ESR Firefox not consume so large amount of RAM?

It is likely not specific to ESR versions. The add-on was updated last month, on August 6th. It is possible that the regression was introduced in a recent version. I recommend reporting this issue with the add-on author.

2. Why, after manually execute GC, memory usage drops down?

How did you draw this conclusion? Could you share the about:memory report before and after forcing GC?

Thanks for your help so far! If you need anything, please feel free to contact me.

Firefox Nightly includes a memory profiler. Since the issue is likely specific to the add-on, could you try enabling the profiler at https://profiler.firefox.com/ , starting a profile, doing your regular browsing (ideally without sensitive activity), and share the profile? This would enable me to see what exactly contributes to the memory increase.

Comment 8

[dzyszla]

Attachment: Memory report befor GC call

Comment 9

[dzyszla]

Attachment: Memory report after call GC

Comment 10

[dzyszla]

I attached report just before and just after click GC on about:memory page.

I'm not sure, what exactly should I do with profiler - Will I install nightly version? The profiler is available in regular too, and can click near the 'extensions' position on about:processes - isn't that enough?

Comment 11

[vcarciu]

After reading the comments I will change the status from Unconfirmed to New, waiting for a resolution related to before/after GC call.

Comment 12

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to dzyszla from comment #10)

I attached report just before and just after click GC on about:memory page.

I'm not sure, what exactly should I do with profiler - Will I install nightly version? The profiler is available in regular too, and can click near the 'extensions' position on about:processes - isn't that enough?

You can enable the profiler on a regular release Firefox version, from this website https://profiler.firefox.com/ click on the "Enable Firefox Profiler Menu Button" make it to appear.

Then you can start to record a profile before the issue is hit and then stop a little bit after the menory usage did grow. When you stop the profiler it will open a new tab to the profiler webapp UI and you can get a shareable link to that profile from there.

Comment 13

[dzyszla]

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #12)

(...) before the issue is hit and then stop a little bit after the menory usage did grow
But it is not one moment. Usage grows systematically and all the time until I either call GC itself or enable/disable any(!) extension (probably this forces GC?). So, how to make measuring best way?

Comment 14

[dzyszla]

Sorry, quote marking mistake. One more time my question:

But it is not one moment. Usage grows systematically and all the time until I either call GC itself or enable/disable any(!) extension (probably this forces GC?). So, how to make measuring best way?

Comment 15

[Rob Wu [:robwu]]

The profiler uses a circular buffer, so you can record a period of time while interacting with the browser in a way that usually results in the memory growth, then trigger GC and stop the recording shortly after to capture it for sharing. Ideally the profile would show the activity from the extension that over time results in excessive memory usage.

Comment 16

[dzyszla]

Ok, here is report: https://share.firefox.dev/3z2R7R1