1552615 - very high vsize 20,907.89 MB, 2,350 MB on a fresh browser, in WebExtensions PID

Status: RESOLVED INCOMPLETE

(WebExtensions :: General, defect, P3)

Description

[Shawn Landden]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

go to about:memory, click "Measure", click "WebExtensions" PId on right

Actual results:

20,907.89 MB ── vsize
6,143.88 MB ── wasm-guard-pages
0.00 MB ── wasm-runtime

Or on a fresh nightly browser/profile

2,350.25 MB ── vsize
0.00 MB ── wasm-runtime

Expected results:

An amount of VM that won't break 32-bit Firefox.

Comment 1

[Eric Rahm [:erahm]]

Shawn can you give us a more detailed STR (what pages and extensions to load, etc) and attach a memory report from when you see this behavior? Also please note there are different heuristics for wasm guard pages on 32-bit builds of Firefox.

Comment 2

[Shawn Landden]

Attachment: memory-report.json.gz

This is a memory report from a fresh start of Firefox nightly with a new profile on Ubuntu Disco x86_64.

Comment 3

[Eric Rahm [:erahm]]

Okay, a 2GB vsize isn't unexpected on 64-bit linux and shouldn't be a major problem (you have something like 256 TiB available per process). The resident and resident-unique numbers look okay as well.

20GB is a bit surprising, I'd definitely like to see a memory report from when that happens again.

Comment 4

[Shawn Landden]

Attachment: memory-report.json.gz

Memory report of the Firefox I am using to submit the file.

Comment 5

[Rares Doghi, Desktop QA]

Hi Eric, Can you helps us find the correct component for this issue ? Does this belong to Memory Allocator ? or maybe something more related to web Extensions?

Comment 6

[Eric Rahm [:erahm]]

Kris, do you know where this should end up? I think we decided this was probably WebExtensions using WASM. That's not necessarily a bug, but we only seem to be reporting 1 set of WASM guard pages when clearly there are at least 3:

20,929.87 MB ── vsize
6,143.88 MB ── wasm-guard-pages
0.00 MB ── wasm-runtime

I'm not sure what rules we have for WebExtensions using WASM, but I'd guess we consider it okay as long as compilation is part of the build step.

Comment 7

[Rares Doghi, Desktop QA]

Hi, I'm setting the component for this issue to WebExtensions since it might be related to it, in case its not please change the component to the correct one, maybe Kris can help us with that.

Comment 8

[marc.2377]

I believe this is definitely related to uBlock Origin. I found this thread on Reddit: https://www.reddit.com/r/uBlockOrigin/comments/b7j45j/ublock_118_memory_leak_on_firefox_up_to_25g_on/

On my computer I just disabled uBlock Origin and saw vsize go from 20.5 GiB to 2.5 GiB instantly.

Shawn, can you please confirm?

Comment 9

[yabepi1183]

This is a bug in Firefox not uBlock Origin however you can find reproduction steps using uBlock Origin at https://github.com/uBlockOrigin/uBlock-issues/issues/811.

Comment 10

[timo]

I can confirm this - I still have this issue.

This is a firefox bug either way you look at it. Even if it is an extention, it should not be able to allocate 26Gb of virtual memory in a managed javascript sandbox style environment. If nothing else, there should be a config mechanism to manage a vzise limit for threads like the webextension thread.

  1.50 MB ── js-main-runtime-temporary-peak
   9,568 ── page-faults-hard
  11,922,780 ── page-faults-soft
  297.93 MB ── resident
  511.52 MB ── resident-peak
 246.20 MB ── resident-unique
 0.86 MB ── script-preloader-memmapped-cache
19.38 MB ── shmem-allocated
19.38 MB ── shmem-mapped
 0.00 MB ── system-heap-allocated
       0 ── unresolved-ipc-responses
27,440.82 MB ── vsize
 0.00 MB ── wasm-runtime

Comment 11

[[e-mail]]

(In reply to Rares Doghi from comment #7)

I'm setting the component for this issue to WebExtensions since it might be related to it

It's a WebAssembly "issue" -- using quotes because it's only about virtual memory here, not actual physical memory; 64-bit OSes have 256 TB of addressable space.

Disabling WASM usage in uBO[1] will not cause the vsize figure to climb, but at the cost of uBO being less performant and for no actual, real physical world gain in return.

[1] https://github.com/gorhill/uBlock/wiki/Advanced-settings#disablewebassembly

Comment 12

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

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED, closing the bug as incomplete.

For more information, please visit BugBot documentation.