thread spawn is broken on wasm32-wasip1-threads stable and beta

[oligamiq]

I tried this code:

fn main() {
    println!("Hello, world!");

    std::thread::spawn(|| {
        println!("Hello from a thread!");
    });
}

https://github.com/[oligamiq/small_example_rust_wasi_threads](https://github.com/oligamiq/small_example_rust_wasi_threads)

I expected to see this happen: success

Hello, world!
Hello from a thread!

Instead, this happened: error

I think cause is memory maximum size.

Meta

rustc --version --verbose:

binary: rustc
commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2
commit-date: 2025-08-04
host: x86_64-pc-windows-msvc
release: 1.89.0
LLVM version: 20.1.7

If I compile on nightly success, but stable and beta is failed.

Backtrace

$ wasmtime run -Sthreads=y --env RUST_MIN_STACK=16777216 --env RUST_BACKTRACE=full target/wasm32-wasip1-threads/release/test_threads.wasm
Hello, world!

thread 'main' (1) panicked at /rustc/1bffa230015ba3c7826f6c5aceb0dc6e940d357e/library/std/src/thread/mod.rs:729:29:
failed to spawn thread: Os { code: 6, kind: WouldBlock, message: "Resource temporarily unavailable" }
stack backtrace:
Error: failed to run main module `target/wasm32-wasip1-threads/release/test_threads.wasm`

Caused by:
    0: failed to invoke command default
    1: error while executing at wasm backtrace:
           0:   0xb6cf - test_threads-ce37a0975add347a.wasm!abort
           1:   0x449b - test_threads-ce37a0975add347a.wasm!std::sys::pal::wasip1::helpers::abort_internal::ha2d25ad2d8cc7f4e
           2:   0x17b4 - test_threads-ce37a0975add347a.wasm!std::process::abort::h06e331628cc7e917
           3:   0x1830 - test_threads-ce37a0975add347a.wasm!__rustc[139b45624945a7]::__rust_abort
           4:   0x1572 - test_threads-ce37a0975add347a.wasm!__rustc[139b45624945a7]::__rust_start_panic
           5:   0x1597 - test_threads-ce37a0975add347a.wasm!__rustc[139b45624945a7]::rust_panic
           6:   0x5d1f - test_threads-ce37a0975add347a.wasm!std::panicking::panic_with_hook::h494c843b894c8787
           7:   0x4a8d - test_threads-ce37a0975add347a.wasm!std::panicking::panic_handler::{{closure}}::h7a990ca68568b775
           8:   0x1947 - test_threads-ce37a0975add347a.wasm!std::sys::backtrace::__rust_end_short_backtrace::h1e0c403cdc0fde71
           9:   0x193b - test_threads-ce37a0975add347a.wasm!__rustc[139b45624945a7]::rust_begin_unwind
          10:   0xed97 - test_threads-ce37a0975add347a.wasm!core::panicking::panic_fmt::h260e9d308beda581
          11:  0x11d8b - test_threads-ce37a0975add347a.wasm!core::result::unwrap_failed::hdc2606fb8c12cedb
          12:    0x846 - test_threads-ce37a0975add347a.wasm!test_threads::main::h9b1b0a14a2d97b85
          13:    0xd46 - test_threads-ce37a0975add347a.wasm!std::sys::backtrace::__rust_begin_short_backtrace::h9f60aca04349e757
          14:    0xd39 - test_threads-ce37a0975add347a.wasm!std::rt::lang_start::{{closure}}::h06fc91a3362ae845
          15:   0x354f - test_threads-ce37a0975add347a.wasm!std::rt::lang_start_internal::h7d02d03e02ad0b2f
          16:   0x1512 - test_threads-ce37a0975add347a.wasm!__main_void
          17:    0x4dd - test_threads-ce37a0975add347a.wasm!_start
    2: wasm trap: wasm `unreachable` instruction executed

Stack backtrace:
   0: wasmtime_set_vmctx_memory_36_0_2
   1: wasmtime_set_vmctx_memory_36_0_2
   2: wasmtime_set_vmctx_memory_36_0_2
   3: wasmtime_set_vmctx_memory_36_0_2
   4: _jit_debug_register_code
   5: _jit_debug_register_code
   6: _jit_debug_register_code
   7: _jit_debug_register_code
   8: SetSecurityDescriptorControl
   9: RtlUserFiberStart

[Noratrieb]

@g0djan @alexcrichton @abrown @loganek as maintainers of the target, as this seems like the feature of the target?

[alexcrichton]

The problem is here where on stable/beta that set of features is different than on nightly. Nightly releases of wasm32-wasip1-threads have always worked and it looks like stable releases of wasm32-wasip1-threads have never worked. Well I suppose that's one way to verify that there are no users of the stable target...

The fix is likely to test something else instead of target features there, or a different set of target features.

[bjorn3]

Given that the atomics feature is unstable, it should probably check sess.unstable_target_features rather than sess.target_features.

[g0djan]

Doesn't seem good. Have you tried another runtime? e.g. WAMR

Also I'm not sure if we ever checked it on runtimes running on windows machines.

[g0djan]

Last time I saw such an error - it was spawning loads of threads in a loop. But that was due to absense of proper pthread_join call for the target and using "cond_var" for that instead which was by design.