304810 2025-12-31 12:01:36 -0800 High memory usage in WASM compilation thread 2026-04-26 15:46:12 -0700 1 1 1 Unclassified WebKit WebAssembly Safari 26 Mac (Apple Silicon) iOS 26 NEW InRadar P2 Normal --- 307107 307389 307583 307686 307990 308158 309992 1 jdolan webkit-unassigned ap furkan.arabaci keith_miller ldenoue nham syg valters.and.co webkit-bug-importer oldest_to_newest 2168727 0 jdolan 2025-12-31 12:01:36 -0800 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. 2168961 1 jdolan 2026-01-02 16:20:53 -0800 Small update, ASYNCIFY_REMOVE on the functions that do unaligned access also prevents the leak. Guessing the stack save/restore system is bypassing something. 2170052 2 webkit-bug-importer 2026-01-07 12:02:12 -0800 <rdar://problem/167709015> 2170061 3 keith_miller 2026-01-07 13:03:56 -0800 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... 2183536 4 ldenoue 2026-02-20 14:25:55 -0800 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 2183541 5 syg 2026-02-20 14:32:48 -0800 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. 2189769 6 nham 2026-03-12 15:59:05 -0700 *** Bug 309251 has been marked as a duplicate of this bug. *** 2204572 7 valters.and.co 2026-04-26 01:59:25 -0700 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" 2204574 8 valters.and.co 2026-04-26 02:01:37 -0700 just to add - maybe this isn't webkit bug at all, but something in the way emscripten generates asyncify code 2204640 9 jdolan 2026-04-26 11:23:30 -0700 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. 2204684 10 valters.and.co 2026-04-26 15:46:12 -0700 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