Bug 304810 – High memory usage in WASM compilation thread

• Status: NEW
• Component: WebAssembly

[James Dolan]

Under certain circumstances I am observing that Safari (26.2 + TP 234) on macOS and iOS can enter a stage of perpetual memory leaking attributed to "Page" that continues even after WASM code exits and eventually results in out-of-memory crash + page reset.

Currently those circumstances appears to be compiling via Emscripten with ASYNCIFY enabled (even if we never hit a Asyncify import), and reading or writing 64-bit values to memory aligned to 4B boundaries.

I have not yet been able to trigger the issue in contrived test so there but I have encountered it in a few different libraries (GLSlang and Tint), this repro (https://github.com/jamesdolan/safari_leak) triggers it in GLSlang and also has a small fix (https://github.com/KhronosGroup/glslang/pull/4137) to avoid the alignment issues that appears to completely avoid the leak.

This leaked memory also does not appear to show up in memory snapshots at all, or really anywhere besides "Page". And have not been able to find anything in the same order of magnitude when dumping out objects in the js console. So this feels like internal allocations.

[James Dolan]

Small update, ASYNCIFY_REMOVE on the functions that do unaligned access also prevents the leak. Guessing the stack save/restore system is bypassing something.

[Radar WebKit Bug Importer]

<rdar://problem/167709015>

[Keith Miller]

Not sure what's going on here but unaligned load/stores in JSC won't do anything special (especially on Apple Silicon which natively supports them).

If it's related to asyncify my guess is that some promise somewhere isn't running or removing itself from some collection after running although it does seem like that should show up in a heap snapshot...

[Laurent Denoue]

This may cause what we see here https://github.com/microsoft/onnxruntime/issues/26827

This unfortunate bug causes many AI models loaded through ONNX runtime to fail on iOS 26, when it was perfect on iOS 18.

Laurent

[Shu-yu Guo]

The unaligned loads are likely to have been a red herring. We've been addressing this issue and the ONNX issue by improving the greedy register and stack allocators in e.g. 306945@main.

[Ben Nham]

*** Bug 309251 has been marked as a duplicate of this bug. ***

[Walter B.]

still present in iOS 26.4.2 - yes it's related to asyncify

I solved it by running:
wasm-opt "${filename}.wasm" -Oz --asyncify -o "${filename}.wasm"

[Walter B.]

just to add - maybe this isn't webkit bug at all, but something in the way emscripten generates asyncify code

[James Dolan]

Cross referencing emscripten issue https://github.com/emscripten-core/emscripten/issues/26027

Also interesting reapplying transform via binarygen appears to resolve issue. Although the fact that memory continues to run away after execution finishes feels like there must be an underlying WebKit issue as well.

[Walter B.]

in the end the way i could properly prevent crash is this:
wasm-opt "${filename}.wasm" --optimize-instructions --licm  --local-cse --code-pushing --merge-locals --coalesce-locals --asyncify -o "${filename}.wasm"
or better yet (but slower)
wasm-opt "${filename}.wasm" --asyncify  --optimize-instructions --licm  --local-cse --code-pushing --merge-locals --coalesce-locals -o "${filename}.wasm"

it's essential that --asyncify is included and .wasm is stripped of symbols enough that wasm-opt won't complain about previous asyncify strings

I analyzed this issue in depth, yes there is definetly an iOS/WebKit  bug, I can zero out wasm memory, remove all timers, remove everything from DOM, remove all messages, everything and it still crashes after about a minute or two once the offending web assembly code has been executed.
This could be both emscripten and iOS bug