github-actions[bot] commented on Issue #1802:
Subscribe to Label Action
cc @bnjbvr
<details>
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64"Thus the following users have been cc'd because of the following labels:
- bnjbvr: cranelift
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
cfallin commented on Issue #1802:
Hmm, the CI seems to be hitting a test timeout (or just a really slow test -- our aarch64 tests run under qemu on the x86 CI hosts):
test wast::Cranelift::spec::start ... test wast::Cranelift::spec::start has been running for over 60 seconds error: test failed, to rerun pass '-p wasmtime-cli --test all'
Not sure what's going on -- did tests pass for you locally?
akirilov-arm commented on Issue #1802:
I usually test with
cargo test --all --exclude lightbeam
. However, I run everything in an actual AArch64 environment - no emulation.
akirilov-arm edited a comment on Issue #1802:
I usually test with
cargo test --all --exclude lightbeam
, which passes locally. However, I run everything in an actual AArch64 environment - no emulation.
cfallin commented on Issue #1802:
I re-kicked the tests; likely just a spurious issue then. If still not green then I can look into the timeout settings.
cfallin commented on Issue #1802:
It appears there's a merge conflict now since we merged Joey's PR (#1801) -- sorry about that!
akirilov-arm commented on Issue #1802:
Now the build fails for reasons that are completely unrelated to my changes:
``error: use of deprecated item 'region::protect::Protection::ReadWrite': Use Protection::READ_WRITE instead --> crates/runtime/src/mmap.rs:185:55 | 185 | unsafe { region::protect(ptr.add(start), len, region::Protection::ReadWrite) } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note:
-D deprecatedimplied by
-D warnings`error: aborting due to previous error
error: could not compile
wasmtime-runtime
.~~~
cfallin commented on Issue #1802:
Yep, I'm seeing the same CI build failure elsewhere; raised the issue on Zulip.
cfallin commented on Issue #1802:
@akirilov-arm we've fixed the CI issue on master, so if you rebase, the tests should pass now. Sorry about all the trouble!
akirilov-arm commented on Issue #1802:
It's still not clear to me why there are failures - this is the only information that I find in the log:
2020-06-03T22:34:04.7756111Z error: test failed, to rerun pass '-p wasmtime-cli --test all' 2020-06-03T22:34:04.8390830Z 2020-06-03T22:34:04.8395010Z Caused by: 2020-06-03T22:34:04.8429995Z process didn't exit successfully: `/home/runner/qemu/bin/qemu-aarch64 -L /usr/aarch64-linux-gnu /home/runner/work/wasmtime/wasmtime/target/aarch64-unknown-linux-gnu/release/deps/all-1543c4079f5cddb8` (signal: 9, SIGKILL: kill) 2020-06-03T22:34:04.9333419Z ##[error]Process completed with exit code 101.
In particular, the tests that my changes are supposed to enable pass.
akirilov-arm commented on Issue #1802:
@cfallin I'll give it another try after the recently merged test fixes.
akirilov-arm commented on Issue #1802:
I am unable to get any useful log output from the latest CI failure - it looks like a timeout?
I have also tried running the tests locally on a x86 machine with QEMU 5.0.0. I used the following command line (based on what CI is doing):
QEMU_LD_PREFIX=/usr/aarch64-linux-gnu cargo test --features test-programs/test_programs --release --all --exclude lightbeam --exclude peepmatic --exclude peepmatic-automata --exclude peepmatic-fuzzing --exclude peepmatic-macro --exclude peepmatic-runtime --exclude peepmatic-test --exclude wasmtime-fuzz --target aarch64-unknown-linux-gnu
Everything completes successfully.
@cfallin I am at a loss about how to proceed. It looks like everything is correct on my end and I am just blocked by CI issues.
akirilov-arm edited a comment on Issue #1802:
I am unable to get any useful log output from the latest CI failure - it looks like a timeout?
I have also tried running the tests locally on a x86 machine with QEMU 5.0.0. I have used the following command line (based on what CI is doing):
QEMU_LD_PREFIX=/usr/aarch64-linux-gnu cargo test --features test-programs/test_programs --release --all --exclude lightbeam --exclude peepmatic --exclude peepmatic-automata --exclude peepmatic-fuzzing --exclude peepmatic-macro --exclude peepmatic-runtime --exclude peepmatic-test --exclude wasmtime-fuzz --target aarch64-unknown-linux-gnu
Everything completes successfully.
@cfallin I am at a loss about how to proceed. It looks like everything is correct on my end and I am just blocked by CI issues.
cfallin commented on Issue #1802:
Sorry the CI is being so temperamental... I kicked the jobs again; let's see what happens. If still an issue, I can ping some others who know more about our CI setup.
cfallin commented on Issue #1802:
Job failed again with a segfault in qemu. Perhaps it's an issue with the qemu setup we have? We appear to be using version 4.2.0, according to the custom qemu build commands in our GitHub CI config. @alexcrichton , is there a way we could use a newer qemu? @akirilov-arm, is there a way you could try to replicate with 4.2.0 (to see if this is a qemu bug)?
alexcrichton commented on Issue #1802:
FWIW segfaults in qemu I've found are typically bugs in qemu (and are somewhat common, especially with things like fanciful instructions). It should be easy enough to update the copy in CI by updating this URL, and if it's working locally with 5.0.0 updating CI should do the trick! If you've got trouble doing that though I'd be happy to help
cfallin commented on Issue #1802:
@akirilov-arm I just rebased your commit on top of our qemu update -- let's see if this works.
akirilov-arm commented on Issue #1802:
FYI QEMU 4.2.0 works for me too. However, I have one remark - I didn't notice any segmentation faults in the old log, rather
SIGKILL
(it was the same error message as the one I posted above). Now, I am not familiar with the CI setup, but if I have to make a wild guess, I'd say we are running out of memory (and the OOM killer springs into action). Of course, I have no idea why any of the other PRs don't fail, including the ones that touch the AArch64 backend. As I said, that's just a wild guess.
alexcrichton commented on Issue #1802:
Yeah it actually sort of looks like OOM of some form since I can't see logs from the builders. One possibility is to turn down the concurrency to just one on aarch64 tests, but otherwise it's probably ok to not enable the tests here just yet and we can figure out how to do that in CI later.
cfallin commented on Issue #1802:
@akirilov-arm if you want to simply re-disable the test, I'm OK with merging this now; maybe open an issue for the
SIGKILL
-afflicted test and add aFIXME
on the line that disables it?
akirilov-arm commented on Issue #1802:
OK, I will rework the patch, so that the vector element extensions go in (we need them for some upcoming changes; for example, I have already implemented what's necessary for
simd_load_extend
, but I have been waiting for this PR to get merged), but I won't enable any tests. Let's revisit them later.
cfallin commented on Issue #1802:
Thanks!
Last updated: Nov 22 2024 at 16:03 UTC