Thread sleep wasm32-wasip2 nightly panics

[Sytten]

I tried this code:

use std::{thread, time::Duration};

fn main() {
    thread::sleep(Duration::from_secs(1));
}

I expected to see this happen: Waits 1s then exit

Instead, this happened: Panic

Meta

The code above works on fine on stable (1.91.1) but panics on nightly 1.94 with wasmtime 39.0.1 and 40.0.0.

Backtrace

thread 'main' (1) panicked at /rustc/a6525d5264da34f51ad48c178281d3c6323dbfcf/library/std/src/sys/thread/unix.rs:539:17:
assertion `left == right` failed
  left: 58
 right: 27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: failed to run main module `target/wasm32-wasip2/debug/wasm-issue.wasm`

Caused by:
    0: failed to invoke `run` function
    1: error while executing at wasm backtrace:
           0:   0x8055 - wasm_issue-a4ab55466b54bfcb.wasm!abort
           1:   0x339e - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::sys::pal::wasi::helpers::abort_internal
           2:   0x2548 - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::process::abort
           3:   0x2b1a - wasm_issue-a4ab55466b54bfcb.wasm!__rustc[75027d40061ac600]::__rust_abort
           4:   0x1049 - wasm_issue-a4ab55466b54bfcb.wasm!__rustc[75027d40061ac600]::__rust_start_panic
           5:   0x2947 - wasm_issue-a4ab55466b54bfcb.wasm!__rustc[75027d40061ac600]::rust_panic
           6:   0x1db3 - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::panicking::panic_with_hook
           7:   0x19c6 - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::panicking::panic_handler::{closure#0}
           8:   0x1918 - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::sys::backtrace::__rust_end_short_backtrace::<std[7c4989414f79d9ff]::panicking::panic_handler::{closure#0}, !>
           9:   0x2bfd - wasm_issue-a4ab55466b54bfcb.wasm!__rustc[75027d40061ac600]::rust_begin_unwind
          10:   0x9885 - wasm_issue-a4ab55466b54bfcb.wasm!core[5e365cd173ca6252]::panicking::panic_fmt
          11:   0x97e2 - wasm_issue-a4ab55466b54bfcb.wasm!core[5e365cd173ca6252]::panicking::assert_failed_inner
          12:   0x1801 - wasm_issue-a4ab55466b54bfcb.wasm!core[5e365cd173ca6252]::panicking::assert_failed::<i32, i32>
          13:   0x3712 - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::thread::functions::sleep
          14:    0xfb3 - wasm_issue-a4ab55466b54bfcb.wasm!wasm_issue[dde815120f543c71]::main
          15:    0xf70 - wasm_issue-a4ab55466b54bfcb.wasm!<fn() as core[5e365cd173ca6252]::ops::function::FnOnce<()>>::call_once
          16:    0xec9 - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
          17:    0xe7d - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::rt::lang_start::<()>::{closure#0}
          18:   0x30c9 - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::rt::lang_start_internal
          19:    0xe43 - wasm_issue-a4ab55466b54bfcb.wasm!std[7c4989414f79d9ff]::rt::lang_start::<()>
          20:    0xfe5 - wasm_issue-a4ab55466b54bfcb.wasm!__main_void
          21:    0xda2 - wasm_issue-a4ab55466b54bfcb.wasm!_start
          22: 0x26794f - <unknown>!wasi:cli/run@0.2.6#run
       note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information
    2: wasm trap: wasm `unreachable` instruction executed

[Sytten]

This is caused by the change of libc in #147572, if possible the full automated test suite should be run since this is a major change. This cant be the only method that broke.

[alexcrichton]

CI tests wasm32-wasip1, not wasm32-wasip2. The wasm32-wasip2 target is a tier 2 target, and thus does not guarantee that all tests are passing. CI furthermore does not run the full test suite on wasm32-wasip1 (or any wasm target) since much of the standard library's tests aren't supported since they require therads, networking, etc.

Put another way, this is expected fallout from #147572, minor breakage here and there. It's not expected that there is a massive set of breakage, so if you see more please report it.

[Sytten]

Will do, what I meant to say is maybe running one the CI for that target would help speed up the process by discovering the broken methods. I dont know much about it, we do have a pretty extensive test suite on wasip2 so I guess I will see on the next nightly if something else is broken.