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 withwasmtime-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:We enable all features during our testing,
wasmtime-environ
will generate the following function:However, for the
wasmtime
package, which is added as a dependency to the overall test, thewmemcheck
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"); }
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 withwasmtime-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:We enable all features during our testing,
wasmtime-environ
will generate the following function:However, for the
wasmtime
package, which is added as a dependency to the overall test, thewmemcheck
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"); }
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.
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
andwasmtime-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 withwasmtime-cranelift/wasmtime-environ
. #8983 added a newwasi-*
crate, which caused the modulus algorithm to group the previously separatedwasmtime-wasi-runtime-config
andwasmtime-cranelift/wasmtime-environ
together.
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.
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 withwasmtime-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:We enable all features during our testing,
wasmtime-environ
will generate the following function:However, for the
wasmtime
package, which is added as a dependency to the overall test, thewmemcheck
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: Dec 23 2024 at 13:07 UTC