Stream: wasmtime

Topic: spec thread tests

Harald Hoyer (Nov 18 2022 at 09:51):

So, I want to activate the tests/spec_testsuite/proposals/threads directory. I worked around the fact, that pooling does not yet work, so I turned it off for this directory...

Nevertheless, I encountered several issues:

• The spec tests wants unaligned atomic as the trap message, whereas in wasmtime it's thrown as misaligned memory access

• the tests/spec_testsuite/proposals/threads/imports.wast seems to check for failure with multiple tables, which is guarded behind cfg.wasm_reference_types(false), so I would have unset this for the directory

• https://github.com/WebAssembly/testsuite/blob/main/proposals/threads/imports.wast#L497-L508 fails with

thread 'wast::Cranelift::spec::threads::imports' panicked at 'called `Result::unwrap()` on an `Err` value: failed directive on tests/spec_testsuite/proposals/threads/imports.wast:486:1

Caused by:
    0: instantiation failed
    1: unknown import: `spectest::shared_memory` has not been defined', /home/harald/git/wasmtime/target/debug/build/wasmtime-cli-c713dba219873d4e/out/wast_testsuite_tests.rs:5193:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    wast::Cranelift::spec::threads::imports

Harald Hoyer (Nov 18 2022 at 09:52):

@Dan Gohman regarding the Trap message, what is the authority here?

Harald Hoyer (Nov 18 2022 at 09:54):

@Alex Crichton other than these failures the proposals/threads spec suite passes :)

Harald Hoyer (Nov 18 2022 at 10:19):

ok, added the shared_memory to the link_spectest

Harald Hoyer (Nov 18 2022 at 11:23):

Hmm, from https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#wait

Wait operators additionally trap if used on an unshared linear memory.
and
https://github.com/WebAssembly/testsuite/blob/3a04b2cf93bd8fce277458d419eea8d9c326345c/proposals/threads/atomic.wast#L438-L443
seem to contradict.

Harald Hoyer (Nov 18 2022 at 14:33):

meh...

Caused by:
  process didn't exit successfully: `/opt/hostedtoolcache/qemu/bin/qemu-riscv64 -L /usr/riscv64-linux-gnu /home/runner/work/wasmtime/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/deps/all-6effd63677afd609` (signal: 9, SIGKILL: kill)

Harald Hoyer (Nov 18 2022 at 14:34):

So, is there a timeout killer? Or what is causing this?

Harald Hoyer (Nov 18 2022 at 14:38):

or is this an OOM killer?

Lann Martin (Nov 18 2022 at 14:46):

Could be; OOM killer will (eventually) send SIGKILL

Alex Crichton (Nov 18 2022 at 15:25):

The spec tests wants unaligned atomic as the trap message, whereas in wasmtime it's thrown as misaligned memory access

It's ok to change the Wasmtime messages to contain the wast testsuite messages at least as a substring

the tests/spec_testsuite/proposals/threads/imports.wast seems to check for failure with multiple tables, which is guarded behind cfg.wasm_reference_types(false), so I would have unset this for the directory

Ah I see these *.wast tests are ancient. If you can figure out how to work around them that's ok, but othewise it's also ok to copy the relevant *.wast tests to tests/misc_testsuite/threads/*.wast or something similar and update them yourself. Or if you're extra intrepid ask upstream if there's any objection to rebasing the proposal.

unknown import: spectest::shared_memory has not been defined',

Looks like you ifgured this one out

So, is there a timeout killer? Or what is causing this?

This is likely related to virtual address space reservations, so you'll probably need to skip the tests when WASMTIME_TEST_NO_HOG_MEMORY is set.

Dan Gohman (Nov 18 2022 at 15:46):

Harald Hoyer said:

Dan Gohman regarding the Trap message, what is the authority here?

The only authority is the tests themselves. Trap messages are not defined in the spec document.

Conrad Watt (Dec 14 2022 at 07:32):

Harald Hoyer said:

Hmm, from https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#wait

Wait operators additionally trap if used on an unshared linear memory.
and
https://github.com/WebAssembly/testsuite/blob/3a04b2cf93bd8fce277458d419eea8d9c326345c/proposals/threads/atomic.wast#L438-L443
seem to contradict.

Just to note, that test is only checking that modules with memory.atomic.wait* validate successfully even if the memory is unshared. Those functions are not actually called in the test - if they were, they would (dynamically) trap.

Conrad Watt (Dec 14 2022 at 07:35):

I only got around to adding tests which capture this recently though

https://github.com/WebAssembly/threads/blob/main/test/core/atomic.wast#L476

it looks like the testsuite repo hasn't been synced yet (reasonable enough, since more changes are on the way and the repo is a bit messy right now).

Last updated: Dec 23 2024 at 13:07 UTC