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 ... okThe 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.
alexcrichton commented on issue #11715:
Do you have
RUST_BACKTRACE=1set 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.
bjorn3 commented on issue #11715:
Yes, I do have
RUST_BACKTRACE=1.
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 ... okThe 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