Stream: git-wasmtime

Topic: wasmtime / issue #11715 Wasmtime tests hanging locally


view this post on Zulip Wasmtime GitHub notifications bot (Sep 19 2025 at 10:23):

bjorn3 opened issue #11715:

$ cargo test
[snip]
test cli_tests::test_programs::cli_serve_trap_before_set has been running for over 60 seconds
test gc::drc_traces_the_correct_number_of_gc_refs_in_arrays has been running for over 60 seconds
test linker::module_interposition has been running for over 60 seconds
test memory::craneliftnative_offsets_static_dynamic_oh_my has been running for over 60 seconds
test memory::craneliftnative_tiny_static_heap has been running for over 60 seconds
test memory::craneliftpulley_offsets_static_dynamic_oh_my has been running for over 60 seconds
test memory::winch_offsets_static_dynamic_oh_my has been running for over 60 seconds
test memory_creator::not_for_windows::host_memory_grow has been running for over 60 seconds
test stack_overflow::craneliftpulley_big_stack_works_ok ... ok
test memory::winch_offsets_static_dynamic_oh_my ... ok
test module::craneliftpulley_concurrent_type_registry_modifications ... ok
test memory_creator::not_for_windows::host_memory_grow ... ok
test gc::drc_traces_the_correct_number_of_gc_refs_in_arrays ... ok
test stack_overflow::craneliftnative_big_stack_works_ok ... ok
test relocs::mixed_forced ... ok
test relocs::mixed ... ok
test memory::craneliftpulley_offsets_static_dynamic_oh_my ... ok
test memory::craneliftnative_tiny_static_heap ... ok
test linker::module_interposition ... ok
test memory::craneliftnative_offsets_static_dynamic_oh_my ... ok

The test binary was using 200% cpu when the warnings about slow execution were printed and dropped to 0% when the couple test passes happened with a wasmtime instance also using 0%. This wasmtime instance is wasmtime serve --addr=127.0.0.1:0 /path/to/wasmtime/target/debug/build/test-programs-artifacts-51f05083d9eb061b/out/wasm32-wasip1/debug/cli_serve_trap_before_set.component.wasm -Scli --shutdown-addr=127.0.0.1:0.

This is on current main (9362e47987363c350a8d9d09aa56677425496fb7) on Linux and consistently reproduces for me.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 19 2025 at 14:56):

alexcrichton commented on issue #11715:

Do you have RUST_BACKTRACE=1 set in your environment? I've seen this befor with that on this specific test and I keep forgetting to either file an issue for it or fix it. Basically the test generates too much output and the server integration we have doesn't work with that.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 19 2025 at 15:01):

bjorn3 commented on issue #11715:

Yes, I do have RUST_BACKTRACE=1.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 23 2025 at 17:49):

fitzgen closed issue #11715:

$ cargo test
[snip]
test cli_tests::test_programs::cli_serve_trap_before_set has been running for over 60 seconds
test gc::drc_traces_the_correct_number_of_gc_refs_in_arrays has been running for over 60 seconds
test linker::module_interposition has been running for over 60 seconds
test memory::craneliftnative_offsets_static_dynamic_oh_my has been running for over 60 seconds
test memory::craneliftnative_tiny_static_heap has been running for over 60 seconds
test memory::craneliftpulley_offsets_static_dynamic_oh_my has been running for over 60 seconds
test memory::winch_offsets_static_dynamic_oh_my has been running for over 60 seconds
test memory_creator::not_for_windows::host_memory_grow has been running for over 60 seconds
test stack_overflow::craneliftpulley_big_stack_works_ok ... ok
test memory::winch_offsets_static_dynamic_oh_my ... ok
test module::craneliftpulley_concurrent_type_registry_modifications ... ok
test memory_creator::not_for_windows::host_memory_grow ... ok
test gc::drc_traces_the_correct_number_of_gc_refs_in_arrays ... ok
test stack_overflow::craneliftnative_big_stack_works_ok ... ok
test relocs::mixed_forced ... ok
test relocs::mixed ... ok
test memory::craneliftpulley_offsets_static_dynamic_oh_my ... ok
test memory::craneliftnative_tiny_static_heap ... ok
test linker::module_interposition ... ok
test memory::craneliftnative_offsets_static_dynamic_oh_my ... ok

The test binary was using 200% cpu when the warnings about slow execution were printed and dropped to 0% when the couple test passes happened with a wasmtime instance also using 0%. This wasmtime instance is wasmtime serve --addr=127.0.0.1:0 /path/to/wasmtime/target/debug/build/test-programs-artifacts-51f05083d9eb061b/out/wasm32-wasip1/debug/cli_serve_trap_before_set.component.wasm -Scli --shutdown-addr=127.0.0.1:0.

This is on current main (9362e47987363c350a8d9d09aa56677425496fb7) on Linux and consistently reproduces for me.


Last updated: Dec 06 2025 at 06:05 UTC