Stream: git-wasmtime

Topic: wasmtime / issue #10982 riscv64: Bus error on qemu when e...

Wasmtime GitHub notifications bot (Jun 09 2025 at 14:31):

akldc opened issue #10982:

.clif Test Case

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true


function u1:1() ->  i64 fast {
    ss1 = explicit_slot 32
    const0 = 0x138570c7f69308b3f282b35c6e347036

block0:
    v8 = iconst.i64 -2844296266602371941
    stack_store v8, ss1
    stack_store v8, ss1+8
    stack_store v8, ss1+16
    stack_store v8, ss1+24
    v27 = stack_addr.i64 ss1+5
    v28 = atomic_cas.i64 v27, v8, v8
    return v28
}

; print: %main()

Versions and Environment

Target Architecture: riscv64
Environment: qemu-riscv64 to emulate execution on an x86 machine.

Results

When executing this test case, qemu crashes with a bus error and returns exit code -7.

Wasmtime GitHub notifications bot (Jun 09 2025 at 14:31):

akldc added the bug label to Issue #10982.

Wasmtime GitHub notifications bot (Jun 09 2025 at 14:31):

akldc added the cranelift label to Issue #10982.

Wasmtime GitHub notifications bot (Jun 09 2025 at 14:33):

alexcrichton added the cranelift:area:riscv64 label to Issue #10982.

Wasmtime GitHub notifications bot (Jun 09 2025 at 14:44):

bjorn3 commented on issue #10982:

atomic_cas is implemented using lr/sc, which require the argument to be aligned to the size of the value that is being swapped, so in your case it has to be 8 bytes aligned. stack_addr.i64 ss1+5 is only 1 byte aligned however, so you get a trap.

Wasmtime GitHub notifications bot (Jun 10 2025 at 05:53):

akldc commented on issue #10982:

@bjorn3
Thanks for the explanation.
I've found another case with unaligned access, but instead of trapping, it runs normally — though the result differs from other architectures.

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true


function %main() -> i64,i16 fast {

    ss0 = explicit_slot 32
    const0 = 0xddbdc3ce969edd942a5e015b5cc8e67d

block0:
    v3 = iconst.i16 -19180
    v5 = iconst.i64 0x4022_9130_1451_b514
    stack_store v5, ss0
    stack_store v5, ss0+8
    stack_store v5, ss0+16
    stack_store v5, ss0+24
    v15 = stack_addr.i64 ss0+3
    v16 = load.i64 v15
    v17 = atomic_cas.i16 v15, v3, v3
    return v16,v17
}

; print: %main()

[x86    ] %main() -> [5887634353547194388, 12308]
[aarch64] %main() -> [5887634353547194388, 12308]
[riscv64] %main() -> [5887634353547194388, 20]

Wasmtime GitHub notifications bot (Jun 15 2025 at 16:52):

alexcrichton closed issue #10982:

.clif Test Case

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true


function u1:1() ->  i64 fast {
    ss1 = explicit_slot 32
    const0 = 0x138570c7f69308b3f282b35c6e347036

block0:
    v8 = iconst.i64 -2844296266602371941
    stack_store v8, ss1
    stack_store v8, ss1+8
    stack_store v8, ss1+16
    stack_store v8, ss1+24
    v27 = stack_addr.i64 ss1+5
    v28 = atomic_cas.i64 v27, v8, v8
    return v28
}

; print: %main()

Versions and Environment

Target Architecture: riscv64
Environment: qemu-riscv64 to emulate execution on an x86 machine.

Results

When executing this test case, qemu crashes with a bus error and returns exit code -7.

Wasmtime GitHub notifications bot (Jun 15 2025 at 16:52):

alexcrichton commented on issue #10982:

I believe this is generally expected behavior where it's effectively UB to do atomics with unaligned addresses. In the i64 case the native instructions generate a fault, and in the i16 case the polyfill for what the platform doesn't support doesn't work correctly. Given that I believe this is all expected behavior, so I'm going to close this.

Last updated: Dec 06 2025 at 07:03 UTC