Wasmtime looks like it was broken from the load_splat
PR: https://github.com/bytecodealliance/wasmtime/commits
@Chris Fallin, @Anton Kirilov: @Johnnie Birch and I initially thought it was an FP conversion PR that did it but then noticed that there were a few more places in https://github.com/bytecodealliance/wasmtime/pull/2278 that need a SourceLoc
Hmm, rebase issue it looks like
My current guess on what went wrong is that in the time between creating the load_splat
PR and merging we added more instructions that use Inst::xmm_rm_r
and the load_splat
PR adds a parameter to that method
Yeah it looks like it. I can revert in the meantime then we can re-land
I wouldn't be opposed to a new PR that just fixes those places
shouldn't be too many: 14 at this point
That's fine too if it's a small fix (I haven't looked in detail) -- thanks!
Ok, I'll tag you guys in a PR in a few minutes
@Andrew Brown @Chris Fallin If it is just that, can we push a fix instead of reverting?
Yeah, I'm building it right now
https://github.com/bytecodealliance/wasmtime/pull/2335
Yes .. it looks like incorrect number of parameters for some lowering functions on the x64 side. One of us .. but I'd be happy to take a stab now at a patch.
Thanks @Andrew Brown, that was quick!
Let's see how the CI reacts... :fingers_crossed:
Ah, looks like one was missed (x64/emit_tests.rs)
Bleh
Ok, it's building again..
Although looks like a failure first occurs in the patch before mine, but looks like most the changes are in my code. An API change was merged as my tests were running. I just pushed a PR for a fix here: https://github.com/bytecodealliance/wasmtime/pull/2337
Oh .. lol. Looks like I was missing some of the conversation. I guess there are two patches. I can delete mine.
@Johnnie Birch no worries, was just looking to see if we were missing something... thank you though :-)
I'd also like to thank @Andrew Brown for the quick fix!
So we fixed the broken CI, right? I just merged a pretty innocuous patch adding pmin/pmax support and the CI, which passed on the PR after a rebase on main, broke on main when I merged it in. The errors are:
(assert_return (invoke "f32x4.neg" (v128.const f32x4 0x0p+0 0x0p+0 0x0p+0 0x0p+0)) (v128.const f32x4 -0x0.0p+0 -0x0.0p+0 -0x0.0p+0 -0x0.0p+0))
(assert_return (invoke "f64x2.neg" (v128.const f64x2 0x0p+0 0x0p+0)) (v128.const f64x2 -0x0.0p+0 -0x0.0p+0))
(assert_return (invoke "f32x4.abs_with_const") (v128.const f32x4 0 1 2 3))
Since none of these are obviously related to anything we've done recently, these tests have been passing consistently for ages, and the subsequent commits all pass, I propose we just observe and see if it happens again. But, yeah, please keep an eye out for this...
@Alex Crichton, more breakages: curl: (6) Could not resolve host: git.io
in https://github.com/bytecodealliance/wasmtime/runs/2015963896?check_suite_focus=true
I merged https://github.com/bytecodealliance/wasmtime/pull/2699 so let's see if the DNS resolution is fixed
And another weird failure: thread 'main' panicked at 'success: Os { code: 2, kind: NotFound, message: "No such file or directory" }', tests/all/debug/gdb.rs:30:31
in https://github.com/bytecodealliance/wasmtime/runs/2016650452?check_suite_focus=true#step:13:119
Anyone know what is going on when the "publish gh-pages" step fails? See https://github.com/abrown/wasmtime/runs/2603472822?check_suite_focus=true#step:13:12.
Related to this being a fork maybe? It feels like a "key is only available in canonical repo" sort of issue...
weirdly if I take the last main-repo CI run it looks like that step is skipped ("/" icon): https://github.com/bytecodealliance/wasmtime/runs/2603390153?check_suite_focus=true
What you've linked there (the disabled step) is disabled because it's on a branch != main (a PR) -- after it was merged, the gh-push in "Publish" happened: <https://github.com/bytecodealliance/wasmtime/runs/2603915443?check_suite_focus=true>. the config controlling this is <https://github.com/bytecodealliance/wasmtime/blob/main/.github/workflows/main.yml#L591>
The step failed for @Andrew Brown 's fork because it was run -- there was push to that fork's main
. It's not supposed to be run for forks, which usually use a different branch -- for the reason @Chris Fallin mentioned, secrets.
Ah, that sort of makes sense. I did push main to my fork so that I could see better which of my branches I should delete. I guess I didn't know that the CI would build my fork...
FWIW I think you can disable GitHub Actions explicitly in your fork (in the repo settings) -- this should prevent the problem in the future :-)
just for clarity, looks like me second reference already changed underneath -- the stable link to the config part is s https://github.com/bytecodealliance/wasmtime/blob/18c61cdfa4bf4944dd09a8d383bedd85f6b97b46/.github/workflows/main.yml#L604
Adding something like github.repository == 'bytecodealliance/wasmtime'
would be another option -- any forks will not run that specific step then.
For those interested in CI issues, I've been noticing more failures than normal recently: https://github.com/bytecodealliance/wasmtime/commits/main. Anyone know what's going on?
A few might have been from network errors but I'm seeing some like "4 successful and 19 cancelled checks"?
if a commit is pushed to the main
branch while CI is running on a previous commit, the previous commit's CI is cancelled
to reduce the amount of resources we take in CI
Looks like the latest CI build on main
is failing because of an API limit issue: https://github.com/bytecodealliance/wasmtime/runs/3263984846?check_suite_focus=true#step:12:3507.
@Alex Crichton, @Pat Hickey: looks like wasi_tokio::poll_oneoff_files
is creating issues again. Should I still merge that PR?
yeah that should be fine to merge
Are builds now hanging? https://github.com/bytecodealliance/wasmtime/pull/3177/checks?check_run_id=3294242349? I ran ci/run-tests.sh
on main
locally to see if I could reproduce the hang-up but it finished successfully in 2m 30s.
...or maybe GitHub actions is having problems: https://www.githubstatus.com.
I think main
is broken due to some spurious error: https://github.com/bytecodealliance/wasmtime/runs/7791537726?check_suite_focus=true#step:4:106
cc: @Alex Crichton, @Chris Fallin, @fitzgen (he/him), @Dan Gohman
I was going to remove that mut
but it is actually necessary... some tool seems to be broken
I guess it's the latest update of Rust to 1.63.0: https://github.com/bytecodealliance/wasmtime/runs/7791537726?check_suite_focus=true#step:3:7
sorry just noticed this, I posted https://github.com/bytecodealliance/wasmtime/pull/4691 with what I think is the fix
oh... jinx: https://github.com/bytecodealliance/wasmtime/pull/4692
(and yours is the actual fix... closing)
Last updated: Dec 23 2024 at 14:03 UTC