Bug 304810
| Summary: | High memory usage in WASM compilation thread | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | James Dolan <jdolan> |
| Component: | WebAssembly | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, furkan.arabaci, keith_miller, ldenoue, nham, syg, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 26 | ||
| Hardware: | Mac (Apple Silicon) | ||
| OS: | iOS 26 | ||
| Bug Depends on: | 307107, 307389, 307583, 307686, 307990, 308158 | ||
| Bug Blocks: | |||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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. ***