Repository navigation
Closed as not planned
Labels
C-bugCategory: This is a bug.Category: This is a bug.C-external-bugCategory: issue that is caused by bugs in software beyond our controlCategory: issue that is caused by bugs in software beyond our controlI-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.O-wasmTarget: WASM (WebAssembly), http://webassembly.org/Target: WASM (WebAssembly), http://webassembly.org/regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Description
After updating to Rust 1.90.0, Wasm becomes to be crashed by out of memory.
The reproduce senquence is below:
$ cargo install wasm-pack
$ cargo install miniserve
$ git clone https://github.com/veryl-lang/doc doc_1.89.0
$ cd doc_1.89.0/playground
$ rustup override set 1.89.0
$ wasm-pack build --target web -d html/pkg --no-typescript
$ miniserve html --index index.html -p 8080
access to http://127.0.0.1:8080
$ git clone https://github.com/veryl-lang/doc doc_1.90.0
$ cd doc_1.90.0/playground
$ rustup override set 1.90.0
$ wasm-pack build --target web -d html/pkg --no-typescript
$ miniserve html --index index.html -p 8081
access to http://127.0.0.1:8081
http://127.0.0.1:8080 using Rust 1.89.0 works fine when Build and Format buttons are pushed.
However, http://127.0.0.1:8081 using Rust 1.90.0 is crashed after a short time of pressing the button like below.
My UI is Japanese, they are written like below:
There is not enough memory to open this page.
Try closing other tabs or programs to free up memory.
Error Code: Out of Memory
Meta
rustc --version --verbose:
rustc 1.90.0 (1159e78c4 2025-09-14)
binary: rustc
commit-hash: 1159e78c4747b02ef996e55082b704c09b970588
commit-date: 2025-09-14
host: x86_64-unknown-linux-gnu
release: 1.90.0
LLVM version: 20.1.8
Metadata
Metadata
Assignees
Labels
C-bugCategory: This is a bug.Category: This is a bug.C-external-bugCategory: issue that is caused by bugs in software beyond our controlCategory: issue that is caused by bugs in software beyond our controlI-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.O-wasmTarget: WASM (WebAssembly), http://webassembly.org/Target: WASM (WebAssembly), http://webassembly.org/regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Activity
[-]Rust 1.90 causes WASM crash by out of memory[/-][+]Rust 1.90 causes Wasm crash by out of memory[/+]xizheyin commentedon Oct 8, 2025
Could it be reproduced in the newest nightly compiler?
dalance commentedon Oct 8, 2025
I checked it.
The latest nightly
rustc 1.92.0-nightly (7c275d09e 2025-09-18)has the same issue.dalance commentedon Oct 8, 2025
I'll try old nightly compilers to find the related commits between 1.89.0 and 1.90.0.
mati865 commentedon Oct 8, 2025
You can use bisect tool to help you with that: https://rust-lang.github.io/cargo-bisect-rustc/
dalance commentedon Oct 8, 2025
I found the affected nightly compiler.
mati865 commentedon Oct 8, 2025
cc @compiler-errors do you have an idea what could have caused this regression?
bjorn3 commentedon Oct 8, 2025
The regression range is ab68b0f...e43d139, right? That range contains the lld stabilization for x86_64 Linux and a bunch of other things.
mati865 commentedon Oct 8, 2025
Sorry, I didn't pay enough attention.
@dalance would it be possible for you to bisect specific commit?
Teapot4195 commentedon Oct 8, 2025
I'm not sure if lld stabilization on x86_64 Linux affects this honestly. I've been trying to bisect the commit but each build does take a while.
EDIT: I did notice that on my system the tab uses 2.7GiB of RAM after clicking build, although it does pass fine, however attempting to then format caused the tab to eat the remaining amount of memory on my system, then crashed in a SIGILL.
mati865 commentedon Oct 8, 2025
@Teapot4195 with https://rust-lang.github.io/cargo-bisect-rustc/ you can download each commit, you don't have to build them yourself.
9 remaining items
dalance commentedon Oct 10, 2025
MCVE is difficult for me because I don't understand the mechanisum of OOM yet.
I found Firefox works fine with wasm of Rust 1.90.0.
So this issue may be caused by Chrome's wasm implementation.
I already uploaded the crash dump to chromium's bug tracker.
If there is any information, I'll feedback to here.
dalance commentedon Oct 10, 2025
I'll try to minimize Rust code.
Teapot4195 commentedon Oct 10, 2025
It may prove useful (if possible) to look into what is allocating all the memory, although I do think there may also be a mis-compile involved here, as the wasm appears to completely hang in some form of busy loop.
dalance commentedon Oct 10, 2025
I removed unnecessary Rust code, and pushed to https://github.com/dalance/wasm_oom_mcve.
ashivaram23 commentedon Oct 16, 2025
I think it's a Chrome bug and d350797 just happened to generate the very specific code required to trigger it. It doesn't crash if you use opt-level 3 or s instead of z, or if you pass
--skip-pass remove-unused-brsor--skip-pass vacuumto wasm-opt. So it looks like it requires a particular rare pattern in the generated wasm.It also works fine if dev tools is open. Maybe Chrome is using less optimization with dev tools for debugging convenience, and the issue is with their more optimizing wasm compiler? This sounds similar to a WebKit bug where some Rust wasm code would wrongly panic half the time because a typo in the lower optimization tier's source code made it take the opposite branch, and fiddling with wasm-opt passes could "fix" it simply by not generating that particular unlucky sequence of instructions. Turboshaft in the v8 engine might be the best place to look if someone has the time to investigate further.
(I wrote the offending commit, sorry 😓)
dalance commentedon Oct 17, 2025
@ashivaram23 Thank you for your feedback. The Chromium issue which I sent was marked as duplicate. I can't see the content of the duplicated issue, but they seem to investigate it.
apiraino commentedon Oct 29, 2025
Thanks for investigating the issue, I am going to close this as "not our bug" (but feel free to reopen if it's the case).
@rustbot label -I-prioritize +C-external-bug +C-gub -E-needs-mcve
dalance commentedon Feb 13, 2026
This issue seems to be resolved when I checked today.
I tried Rust 1.93.1, it works fine. Additionally, Rust 1.90.0 works fine too.
I found the following message while compiling by Rust 1.90.0, std update may be related.
Otherwise, it is also possible that Chrome's update resolved this issue.