Stream: git-wasmtime

Topic: wasmtime / issue #8997 CI: wasi-* crates tests failed due...

Wasmtime GitHub notifications bot (Jul 23 2024 at 08:50):

iawia002 opened issue #8997:

I first encountered this issue at https://github.com/bytecodealliance/wasmtime/pull/8983#issuecomment-2242604361. When the wasi-* crates are grouped with wasmtime-cranelift/wasmtime-environ, the tests will panic:

thread 'runtime_config_get' panicked at crates/wasmtime/src/runtime/vm/libcalls.rs:147:5:
internal error: entered unreachable code
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: wasmtime::runtime::vm::libcalls::raw::malloc_start

So, I looked into the source of this code and eventually found that it is related to the wmemcheck feature:

https://github.com/bytecodealliance/wasmtime/blob/80c42c427d828f6ccf004169d8dd018dc5b4d0f0/crates/wasmtime/src/runtime/vm/libcalls.rs#L120-L123

We enable all features during our testing, wasmtime-environ will generate the following function:

https://github.com/bytecodealliance/wasmtime/blob/80c42c427d828f6ccf004169d8dd018dc5b4d0f0/crates/environ/src/builtin.rs#L56-L58

However, for the wasmtime package, which is added as a dependency to the overall test, the wmemcheck feature is not enabled by default. This combination results in the follow code causing the wasm component program to panic directly:

#[allow(unused_variables, missing_docs)]
pub unsafe extern "C" fn malloc_start(vmctx: *mut VMContext) {
    ::core::panicking::panic("internal error: entered unreachable code");
}

Wasmtime GitHub notifications bot (Jul 23 2024 at 08:59):

iawia002 edited issue #8997:

I first encountered this issue at https://github.com/bytecodealliance/wasmtime/pull/8983#issuecomment-2242604361. When the wasi-* crates are grouped with wasmtime-cranelift/wasmtime-environ, the tests will panic:

thread 'runtime_config_get' panicked at crates/wasmtime/src/runtime/vm/libcalls.rs:147:5:
internal error: entered unreachable code
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: wasmtime::runtime::vm::libcalls::raw::malloc_start

So, I looked into the source of this code and eventually found that it is related to the wmemcheck feature:

https://github.com/bytecodealliance/wasmtime/blob/80c42c427d828f6ccf004169d8dd018dc5b4d0f0/crates/wasmtime/src/runtime/vm/libcalls.rs#L120-L123

We enable all features during our testing, wasmtime-environ will generate the following function:

https://github.com/bytecodealliance/wasmtime/blob/80c42c427d828f6ccf004169d8dd018dc5b4d0f0/crates/environ/src/builtin.rs#L56-L58

However, for the wasmtime package, which is added as a dependency to the overall test, the wmemcheck feature is not enabled by default. This combination results in the following generated code causing the wasm component program to panic directly:

#[allow(unused_variables, missing_docs)]
pub unsafe extern "C" fn malloc_start(vmctx: *mut VMContext) {
    ::core::panicking::panic("internal error: entered unreachable code");
}

Wasmtime GitHub notifications bot (Jul 23 2024 at 20:07):

alexcrichton commented on issue #8997:

Can you clarify a bit more how to trigger this? It's a bit difficult to piece together if this depends on pieces of https://github.com/bytecodealliance/wasmtime/pull/8983 which aren't landed in-tree.

Wasmtime GitHub notifications bot (Jul 24 2024 at 01:26):

iawia002 commented on issue #8997:

Try the following script, which is similar to the one in CI, but I've manually grouped wasmtime-wasi-http and wasmtime-cranelift/wasmtime-environ together to run simultaneously:

./ci/run-tests.sh --locked --package cranelift-tools --exclude cranelift --exclude cranelift-codegen --package cranelift-bforest --exclude cranelift-entity --exclude cranelift-bitset --package cranelift-codegen-shared --exclude cranelift-control --exclude cranelift-codegen-meta --package cranelift-isle --exclude cranelift-frontend --exclude cranelift-interpreter --package cranelift-reader --exclude cranelift-jit --exclude cranelift-module --package cranelift-native --exclude wasmtime-jit-icache-coherence --exclude cranelift-object --package cranelift-filetests --exclude isle-fuzz --exclude islec --package cranelift-serde --exclude wasmtime-bench-api --exclude wasi-common --exclude wasmtime --package wasmtime-asm-macros --exclude wasmtime-cache --exclude wasmtime-component-macro --package wasmtime-component-util --exclude wasmtime-wit-bindgen --exclude component-macro-test-helpers --package wasmtime-cranelift --exclude cranelift-wasm --exclude wasmtime-types --package wasmtime-environ --exclude wasmtime-versioned-export-macros --exclude wasmtime-fiber --package wasmtime-jit-debug --exclude wasmtime-slab --exclude wasmtime-winch --package winch-codegen --exclude wasmtime-wmemcheck --exclude wiggle --package wiggle-macro --exclude wiggle-generate --exclude wiggle-test --package test-programs-artifacts --exclude wasmtime-cli-flags --exclude wasmtime-wasi-nn --exclude wasmtime-wasi --package wasmtime-c-api --exclude wasmtime-c-api-impl --exclude wasmtime-c-api-macros --package wasmtime-environ-fuzz --exclude component-fuzz-util --exclude test-programs --package wasi-preview1-component-adapter --exclude byte-array-literals --exclude verify-component-adapter --package example-fib-debug-wasm --exclude example-wasi-wasm --exclude example-tokio-wasm --package example-component-wasm --exclude min-platform-host --exclude embedding --package wasmtime-fuzz --exclude component-test-util --exclude cranelift-fuzzgen --package wasmtime-fuzzing --exclude wasm-spec-interpreter --exclude wasmtime-wast --exclude wasmtime-cli --package wasmtime-explorer --package wasmtime-wasi-http --exclude wasmtime-wasi-runtime-config --package wasmtime-wasi-threads --exclude component-macro-test --exclude wasmtime-test-macros

Actually, this issue has always existed and is not related to #8983. We haven't encountered it before because the wasi-* crates just happened not to be grouped with wasmtime-cranelift/wasmtime-environ. #8983 added a new wasi-* crate, which caused the modulus algorithm to group the previously separated wasmtime-wasi-runtime-config and wasmtime-cranelift/wasmtime-environ together.

Wasmtime GitHub notifications bot (Jul 24 2024 at 14:47):

alexcrichton commented on issue #8997:

Thanks! I suspected that it was a preexisting issue as well but just wasn't sure how to reproduce it, and the script there is helpful! This should be fixed by https://github.com/bytecodealliance/wasmtime/pull/9002.

Wasmtime GitHub notifications bot (Jul 24 2024 at 16:22):

fitzgen closed issue #8997:

I first encountered this issue at https://github.com/bytecodealliance/wasmtime/pull/8983#issuecomment-2242604361. When the wasi-* crates are grouped with wasmtime-cranelift/wasmtime-environ, the tests will panic:

thread 'runtime_config_get' panicked at crates/wasmtime/src/runtime/vm/libcalls.rs:147:5:
internal error: entered unreachable code
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: wasmtime::runtime::vm::libcalls::raw::malloc_start

So, I looked into the source of this code and eventually found that it is related to the wmemcheck feature:

https://github.com/bytecodealliance/wasmtime/blob/80c42c427d828f6ccf004169d8dd018dc5b4d0f0/crates/wasmtime/src/runtime/vm/libcalls.rs#L120-L123

We enable all features during our testing, wasmtime-environ will generate the following function:

https://github.com/bytecodealliance/wasmtime/blob/80c42c427d828f6ccf004169d8dd018dc5b4d0f0/crates/environ/src/builtin.rs#L56-L58

However, for the wasmtime package, which is added as a dependency to the overall test, the wmemcheck feature is not enabled by default. This combination results in the following generated code causing the wasm component program to panic directly:

#[allow(unused_variables, missing_docs)]
pub unsafe extern "C" fn malloc_start(vmctx: *mut VMContext) {
    ::core::panicking::panic("internal error: entered unreachable code");
}

Last updated: Nov 22 2024 at 16:03 UTC