Stream: git-wasmtime

Topic: wasmtime / issue #7874 wasmtime 17 hangs while trying to ...

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2024 at 20:45):

glebpom added the bug label to Issue #7874.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2024 at 20:45):

glebpom opened issue #7874:

Test Case

https://drive.google.com/file/d/1HYlz78KTuag9bTpNwGP_blp5yWo95i_7/view?usp=sharing

This wasm file successfully loads by version 16, but wasmtime 17 hangs and eats a lot of CPU while trying to load it

Steps to Reproduce

This is reproducible in python and ruby. Example ruby code:

      @engine = Wasmtime::Engine.new
      @mod = Wasmtime::Module.new(@engine, wasm)

Expected Results

Should work

Actual Results

It hangs eating ~170% of CPU

Versions and Environment

Wasmtime version or commit: 17

Operating system: MacOS

Architecture: aarch64

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2024 at 21:25):

pchickey commented on issue #7874:

It appears this is some sort of codegen bug - I was able to reproduce this on main with cargo run --release -- compile v0.2.0.wasm, wasmtime consumes 2 cores for as long as I had the patience for (~4 mins)

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2024 at 21:26):

pchickey added the cranelift:E-compiler label to Issue #7874.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 11:44):

glebpom commented on issue #7874:

I was able to bisect and find the breaking commit, which is:

fac3b9c2d1373c8bdf10b53f2f6e96c01c90afd8 is the first bad commit
commit fac3b9c2d1373c8bdf10b53f2f6e96c01c90afd8
Author: Alex Crichton <alex@alexcrichton.com>
Date:   Thu Jan 25 09:50:19 2024 -0800

    Enable the component model by default

    This commit enables the component model by default in the embedding API
    and the CLI. This means that an opt-in of `-W component-model` is no
    longer required and additionally `.wasm_component_model(true)` is no
    longer required. Note that this won't impact existing embeddings since
    the component model feature doesn't do much less `wasmtime::component`
    is used, and if that's being used this is probably good news for you.

 crates/wasmtime/src/config.rs |  1 +
 src/common.rs                 |  2 +-
 tests/all/cli_tests.rs        | 23 +++++++++++++++++++++++
 3 files changed, 25 insertions(+), 1 deletion(-)

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 11:52):

glebpom edited a comment on issue #7874:

I was able to bisect and find the breaking commit, which is:

fac3b9c2d1373c8bdf10b53f2f6e96c01c90afd8 is the first bad commit
commit fac3b9c2d1373c8bdf10b53f2f6e96c01c90afd8
Author: Alex Crichton <alex@alexcrichton.com>
Date:   Thu Jan 25 09:50:19 2024 -0800

    Enable the component model by default

    This commit enables the component model by default in the embedding API
    and the CLI. This means that an opt-in of `-W component-model` is no
    longer required and additionally `.wasm_component_model(true)` is no
    longer required. Note that this won't impact existing embeddings since
    the component model feature doesn't do much less `wasmtime::component`
    is used, and if that's being used this is probably good news for you.

 crates/wasmtime/src/config.rs |  1 +
 src/common.rs                 |  2 +-
 tests/all/cli_tests.rs        | 23 +++++++++++++++++++++++
 3 files changed, 25 insertions(+), 1 deletion(-)

EDIT: I was bisecting this PR https://github.com/bytecodealliance/wasmtime/pull/7800/commits

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 19:32):

alexcrichton commented on issue #7874:

@glebpom can you clarify how you bisected? My bisection points to https://github.com/bytecodealliance/wasmtime/pull/7719 and looking at a performance profile most of the time is spent in constructor_will_simplify_with_ireduce which helps point to that PR as well.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2024 at 19:54):

glebpom commented on issue #7874:

@alexcrichton yes, you are right. I can't reproduce this anymore, but the commit you pointed to clearly makes it hang.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 05:41):

fitzgen closed issue #7874:

Test Case

https://drive.google.com/file/d/1HYlz78KTuag9bTpNwGP_blp5yWo95i_7/view?usp=sharing

This wasm file successfully loads by version 16, but wasmtime 17 hangs and eats a lot of CPU while trying to load it

Steps to Reproduce

This is reproducible in python and ruby. Example ruby code:

      @engine = Wasmtime::Engine.new
      @mod = Wasmtime::Module.new(@engine, wasm)

Expected Results

Should work

Actual Results

It hangs eating ~170% of CPU

Versions and Environment

Wasmtime version or commit: 17

Operating system: MacOS

Architecture: aarch64

view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 23:53):

elliottt commented on issue #7874:

This should be fixed in the wasmtime 17.0.1 release, thank you again for reporting this!

Last updated: Dec 23 2024 at 12:05 UTC