Stream: wasmtime

Topic: Cargo test for aarch64-unknown-linux-gnu


view this post on Zulip mk89 (Jul 30 2020 at 16:19):

Hi all!

I'm trying to run the tests for the main branch for the target aarch-64-unknown-linux-gnu and it's failing on the test wast::Cranelift::spec::multi_value::binary.

I'm getting the following error message:

test wast::Cranelift::spec::multi_value::binary ... test wast::Cranelift::spec::multi_value::binary has been running for over 60 seconds
error: test failed, to rerun pass '--test all'

Caused by:
  process didn't exit successfully: `/media/share/github/wasmtime/target/aarch64-unknown-linux-gnu/debug/deps/all-4ed39f6a59594088` (signal: 9, SIGKILL: kill)

I tried to follow similar steps of your CI pipeline, where it works perfectly but I'm not using docker. Do you have any idea what could be causing it?

Thank you

view this post on Zulip Alex Crichton (Jul 30 2020 at 16:21):

@mk89 are you using qemu emulation to run aarch64 tests? SIGKILL typically means something was oom-killed

view this post on Zulip mk89 (Jul 30 2020 at 16:23):

Yes, I'm using qemu-aarch64. The VM has 8gb of RAM, I can try to increase it.

view this post on Zulip Alex Crichton (Jul 30 2020 at 16:53):

@mk89 you may want to try using the latest release of qemu

view this post on Zulip Alex Crichton (Jul 30 2020 at 16:53):

additionally you'll probably want to tweak the CLI options for wasmtime to not reserve so much memory

view this post on Zulip Alex Crichton (Jul 30 2020 at 16:53):

wasmtime does the 6gb memory trick, which qemu doesn't handle well since it tries to actually work with all that memory

view this post on Zulip Alex Crichton (Jul 30 2020 at 16:54):

this is what we do on our CI to fix this issue

Standalone JIT-style runtime for WebAssembly, using Cranelift - bytecodealliance/wasmtime

view this post on Zulip mk89 (Jul 30 2020 at 17:05):

Thanks for the tips!

You were right, I increased the ram to 16 GB and it passed (it reached 11.3gb on the qemu-aarch64-static process).

I'm interested in running the tests in the target ARM machine and I probably won't run it with qemu soon enough, but it's possible that I'll have to adjust these values because the SoC has a limited amount of RAM.

What is this trick for?

By the way, would you be interesting in knowing if the test suite passed for the SoCs that I test on?

view this post on Zulip Alex Crichton (Jul 30 2020 at 17:06):

wasmtime reserves a large amount of the address space by default to elide bounds checks on memory accesses

view this post on Zulip Alex Crichton (Jul 30 2020 at 17:06):

but you can configure it to not do that

view this post on Zulip Alex Crichton (Jul 30 2020 at 17:07):

and qemu seems to not pay well with this trick in that it eagerly requests all the memory instead of lazily like wasmtime wants


Last updated: Nov 22 2024 at 16:03 UTC