Open Bug 1992558 Opened 2 months ago Updated 1 month ago

Wasm64 high memory usage/memory leak on Windows prevents running Emscripten 'browser64_4gb' suite to completion

Categories

(Core :: JavaScript: WebAssembly, defect, P1)

Firefox 141
defect

Tracking

()

ASSIGNED

People

(Reporter: jujjyl, Assigned: bvisness)

References

(Blocks 1 open bug)

Details

There is some kind of memory leak or high memory usage bug in Wasm64 implementation, which only manifests on Windows. The issue does not seem to occur on Linux. (MacOS not tested)

This issue occurs in the Emscripten Wasm64 browser test harness, where the test harness runs through about 800 Emscripten compilation test cases.

On Windows, the harness starts to fail in the multithreaded pthread tests. At the time of the failure, Windows Task manager shows only 14/64GB of memory used, but the "Committed" memory usage is very high, 256GB.

To illustrate the issue, here a video walkthrough: https://youtu.be/gyfvM9UR8Lk

In the video,

0:00: the Emscripten 'browser64_4gb' test harness is launched in singlethreaded mode.
0:00 - 1:16: Initially many tests are running ok. The first tests are singlethreaded, and these don't seem to be causing issues.
1:16: The test harness starts to fail. Windows Task Manager shows 256GB of "Committed" memory usage, but very little, 14/64GB of actual memory use. All subsequent tests are failing.
1:58: Peeking in Web console, Uncaught exceptions "out of memory" are seen to be the failure cause in the tests.
3:18: Navigating to about:memory to see what Firefox thinks about the situation.
3:30: Firefox says that it would be using only 1GB of Total resident memory.
4:18: In webCOOP+COEP, a massive 243GB of memory usage is seen.
4:54: Attempting to run the GC, CC and Minimize memory usage buttons in about:memory
5:13: That didn't seem to help, but the 243GB of memory usage persists.
5:15 forward ->: The rest of the video scrolls through the rest of the content displayed in about:memory.

The test harness run recording is stopped short, when OBS crashes in the background to running out of memory as well. I.e. this out of memory situation propagates to other applications on the PC. Windows can show a "Your system is running low on memory." error message.

On my other Windows CI PC, the whole system hangs when attempting to run the browser64_4gb suite, and must be hard-reset from the PC power button.


This out of memory issue seems to be Windows only. Testing this issue on two other Linux systems, one 128-core Ampere Altra ARM64 Debian 13, and another 256-core AMD Epyc 7763 Linux Mint 22 workstation, the out of memory issues do not occur, but one can run up to 64 parallel instances of the Emscripten browser test harness without OOMing.


On the video, the issue is tested on Firefox Nightly, though the issue persists on all versions of Firefox tested so far, e.g. in Firefox 141 stable as well.

Verified that the issue does not occur on Firefox on macOS.

Also, the issue does happen on Firefox on Windows 11-on-ARM64 PC, so this seems Windows only, x64 and ARM CPUs.

Assignee: nobody → bvisness
Status: NEW → ASSIGNED

To reproduce this locally, one can run

git clone https://github.com/emscripten-core/emsdk.git
cd emsdk
emsdk install sdk-main-64bit
emsdk activate sdk-main-64bit
cd emscripten\main
set EMTEST_BROWSER=C:\Program Files\Mozilla Firefox\firefox.exe
test\runner browser

(the install step will take some while, and requires CMake and Visual Studio 22 to be installed. Apologies for a complex setup process)

The last line, test\runner browser will invoke the failing test harness as seen on the video.

Assuming that the root of issue is SharedArrayBuffer/sharing WebAssembly.Memory in Workers, then to speed up the failing test harness, one might be able to run just

test\runner browser.test_pthread* browser.test_wasm_worker*

to only run tests that exercise multithreaded WebAssembly code.

Blocks: wasm64
Severity: -- → S3
Priority: -- → P1
You need to log in before you can comment on or make changes to this bug.