Skip to content

Rust 1.90 causes Wasm crash by out of memory #147465

Closed as not planned
Closed as not planned

Description

@dalance

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.

Image

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

Activity

  1. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Oct 8, 2025
  2. changed the title [-]Rust 1.90 causes WASM crash by out of memory[/-] [+]Rust 1.90 causes Wasm crash by out of memory[/+] on Oct 8, 2025
  3. added
    I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
    O-wasmTarget: WASM (WebAssembly), http://webassembly.org/
    on Oct 8, 2025
  4. xizheyin commented on Oct 8, 2025

    @xizheyin
    Member

    Could it be reproduced in the newest nightly compiler?

  5. dalance commented on Oct 8, 2025

    @dalance
    ContributorAuthor

    I checked it.
    The latest nightly rustc 1.92.0-nightly (7c275d09e 2025-09-18) has the same issue.

  6. dalance commented on Oct 8, 2025

    @dalance
    ContributorAuthor

    I'll try old nightly compilers to find the related commits between 1.89.0 and 1.90.0.

  7. mati865 commented on Oct 8, 2025

    @mati865
    Member

    You can use bisect tool to help you with that: https://rust-lang.github.io/cargo-bisect-rustc/

  8. dalance commented on Oct 8, 2025

    @dalance
    ContributorAuthor

    I found the affected nightly compiler.

    • nightly-2025-07-09 (ab68b0f 2025-07-08) works fine
    • nightly-2025-07-10 (e43d139 2025-07-09) doesn't work
  9. mati865 commented on Oct 8, 2025

    @mati865
    Member

    cc @compiler-errors do you have an idea what could have caused this regression?

  10. bjorn3 commented on Oct 8, 2025

    @bjorn3
    Member

    The regression range is ab68b0f...e43d139, right? That range contains the lld stabilization for x86_64 Linux and a bunch of other things.

  11. mati865 commented on Oct 8, 2025

    @mati865
    Member

    Sorry, I didn't pay enough attention.
    @dalance would it be possible for you to bisect specific commit?

  12. Teapot4195 commented on Oct 8, 2025

    @Teapot4195
    Contributor

    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.

  13. mati865 commented on Oct 8, 2025

    @mati865
    Member

    @Teapot4195 with https://rust-lang.github.io/cargo-bisect-rustc/ you can download each commit, you don't have to build them yourself.

  14. 9 remaining items

  15. dalance commented on Oct 10, 2025

    @dalance
    ContributorAuthor

    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.

  16. dalance commented on Oct 10, 2025

    @dalance
    ContributorAuthor

    I'll try to minimize Rust code.

  17. Teapot4195 commented on Oct 10, 2025

    @Teapot4195
    Contributor

    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.

  18. dalance commented on Oct 10, 2025

    @dalance
    ContributorAuthor

    I removed unnecessary Rust code, and pushed to https://github.com/dalance/wasm_oom_mcve.

    $ cargo install wasm-pack
    $ cargo install miniserve
    
    $ git clone https://github.com/dalance/wasm_oom_mcve
    $ cd wasm_oom_mcve
    $ 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 by Chrome-based browser, push "BUILD" button at the top of the page,
    and the tab of the browser will be crashed caused by out-of-memory error
    
  19. ashivaram23 commented on Oct 16, 2025

    @ashivaram23
    Contributor

    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-brs or --skip-pass vacuum to 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 😓)

  20. dalance commented on Oct 17, 2025

    @dalance
    ContributorAuthor

    @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.

  21. apiraino commented on Oct 29, 2025

    @apiraino
    Contributor

    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

  22. added
    C-external-bugCategory: issue that is caused by bugs in software beyond our control
    C-gubCategory: the reverse of a compiler bug is generally UB
    and removed
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Oct 29, 2025
  23. removed
    E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
    on Oct 29, 2025
  24. removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    C-gubCategory: the reverse of a compiler bug is generally UB
    on Nov 1, 2025
  25. dalance commented on Feb 13, 2026

    @dalance
    ContributorAuthor

    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.

    info: downloading component 'rust-std' for 'wasm32-unknown-unknown'
    info: installing component 'rust-std' for 'wasm32-unknown-unknown'
    
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.C-external-bugCategory: 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.O-wasmTarget: WASM (WebAssembly), http://webassembly.org/regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions