Stream: git-wasmtime

Topic: wasmtime / issue #10000 Spurious (?) CI failures on s390x

Wasmtime GitHub notifications bot (Jan 13 2025 at 20:34):

alexcrichton opened issue #10000:

I've seen two CI builds fail today on the s390x tests of the wasmtime-cli crate:

• https://github.com/bytecodealliance/wasmtime/actions/runs/12752790805/job/35543074991 (https://github.com/bytecodealliance/wasmtime/pull/9982#event-15909676078)
• https://github.com/bytecodealliance/wasmtime/actions/runs/12755184456/job/35550742014 (https://github.com/bytecodealliance/wasmtime/pull/9994#event-15912281849)

The first was re-queued and merged and the second is currently back in the queue. The first didn't touch anything in wasmtime-cli and the second does touch quite a bit that could affect it so it's currently an assumption of mine that the s390x-failure there was specific to s390x.

I tried running the test suite in a loop locally for a bit using s390x/qemu and so far it hasn't failed in the same way. I figured I'd open an issue to keep track of things if they happen in the future.

cc @uweigand

Wasmtime GitHub notifications bot (Jan 16 2025 at 13:34):

iii-i commented on issue #10000:

In my local runs I've seen segfaults due to an ABI problem in the capstone wrapper: https://github.com/capstone-rust/capstone-rs/pull/166. I wonder if this can be related?

Wasmtime GitHub notifications bot (Jan 16 2025 at 17:38):

abrown added the cranelift:area:s390x label to Issue #10000.

Wasmtime GitHub notifications bot (Feb 05 2025 at 00:04):

abrown commented on issue #10000:

Not sure, but I believe I saw a similar failure over in #10110: https://github.com/bytecodealliance/wasmtime/actions/runs/13124822832/job/36618948362#step:18:987.

Wasmtime GitHub notifications bot (Feb 19 2025 at 20:38):

alexcrichton commented on issue #10000:

Another failure at https://github.com/bytecodealliance/wasmtime/actions/runs/13421426149/job/37494891337

Wasmtime GitHub notifications bot (Apr 02 2025 at 16:18):

alexcrichton commented on issue #10000:

another

Wasmtime GitHub notifications bot (May 30 2025 at 21:34):

alexcrichton commented on issue #10000:

another

Wasmtime GitHub notifications bot (Jun 02 2025 at 14:21):

alexcrichton added the ci label to Issue #10000.

Wasmtime GitHub notifications bot (Jun 06 2025 at 20:59):

alexcrichton commented on issue #10000:

another

Wasmtime GitHub notifications bot (Mar 30 2026 at 18:08):

alexcrichton commented on issue #10000:

another

Wasmtime GitHub notifications bot (Apr 06 2026 at 14:20):

alexcrichton commented on issue #10000:

another

Wasmtime GitHub notifications bot (Apr 06 2026 at 16:43):

alexcrichton commented on issue #10000:

another

Wasmtime GitHub notifications bot (Apr 07 2026 at 12:28):

uweigand commented on issue #10000:

Hi @alexcrichton , these seems to be qemu - are we now running CI on qemu again vs. the native GitHub actions? Just wondering whether you've seen any of these segfaults on native as well ...

These qemu failures are hard to reproduce - can we at least try to capture core dumps?

Wasmtime GitHub notifications bot (Apr 07 2026 at 17:40):

alexcrichton commented on issue #10000:

Yeah I believe these are all through QEMU, not native. After the incident awhile back we switched back to QEMU and haven't gone back to native after that so far.

I'd capture core dumps if I knew how to, but I'm not sure how to capture/upload core dumps from github actions :(

I mostly just want to be sure to log these over time to track incident rate, no need to urgently fix or such.

Last updated: Apr 12 2026 at 23:10 UTC