Stream: git-wasmtime

Topic: wasmtime / PR #8941 fuzzgen: Add stack map variables

view this post on Zulip Wasmtime GitHub notifications bot (Jul 11 2024 at 18:08):

afonso360 opened PR #8941 from afonso360:fuzzgen-stack-maps to bytecodealliance:main:

:wave: Hey,

This PR adds the new variable stack map apis (added in #8937) to cranelift fuzzgen.

I've tried to fuzz this for a bit, but it seems to generate invalid functions that don't pass the validator. I don't know enough about how stackmaps work to debug this. (cc @fitzgen)

I also don't know if this feature is ready for fuzzing yet, so if it isn't let me know!

Here's one of the fuzz bugs:

<details>
<summary>Panic</summary>

thread '<unnamed>' panicked at fuzz/fuzz_targets/cranelift-fuzzgen.rs:402:14:
called `Result::unwrap()` on an `Err` value: Compilation error: Verifier errors

Caused by:
    0: Verifier errors
    1: - inst10 (stack_store.f32 v24, ss1): uses value v24 from non-dominating inst6

</details>

<details>
<summary>base64</summary>

/34Vbf91NDQzW23Ny8vLNMvFNDQ3ycvKLjg4ODg4ODAwMHIwMTUxbTMwMDL/Gv8jygI0ODh4MDAwcjAxNTFtMzAwMv8CNDQ0eHg0NDQjygD///8+Pl0+Pj4+PgEBAQEBAQH3AQ==

</details>

<details>
<summary>CLIF</summary>

test interpret
test run
set probestack_size_log2=11
set probestack_strategy=inline
set enable_safepoints=true
set enable_llvm_abi_extensions=true
set preserve_frame_pointers=true
set machine_code_cfg_info=true
set enable_probestack=true
set enable_jump_tables=false
set enable_heap_access_spectre_mitigation=false
set enable_incremental_compilation_cache_checks=true
target x86_64 has_sse3 has_ssse3 has_sse41 has_sse42 has_avx has_avx2 has_fma has_popcnt has_bmi1 has_bmi2 has_lzcnt

function u1:0(i64x2, i16 uext, f32, f64x2, i32x4, i32x4, f32x4, i16x8, i8 sext, i32x4, i8x16, i32 uext, i128, i64 sext) -> i32x4, i32x4, i64x2, i32x4, i64x2, i16 uext, f32, f64x2, i32x4, i32x4, f32x4, i16x8 fast {
    ss0 = explicit_slot 2, align = 2
    ss1 = explicit_slot 4, align = 4
    ss2 = explicit_slot 16, align = 16
    sig0 = (f32) -> f32 system_v
    sig1 = (f64) -> f64 system_v
    sig2 = (f32) -> f32 system_v
    sig3 = (f64) -> f64 system_v
    sig4 = (f32) -> f32 system_v
    sig5 = (f64) -> f64 system_v
    fn0 = %CeilF32 sig0
    fn1 = %CeilF64 sig1
    fn2 = %FloorF32 sig2
    fn3 = %FloorF64 sig3
    fn4 = %TruncF32 sig4
    fn5 = %TruncF64 sig5

block0(v0: i64x2, v1: i16, v2: f32, v3: f64x2, v4: i32x4, v5: i32x4, v6: f32x4, v7: i16x8, v8: i8, v9: i32x4, v10: i8x16, v11: i32, v12: i128, v13: i64):
    v22 -> v0
    v23 -> v1
    v25 -> v3
    v26 -> v6
    v27 -> v7
    v15 = iconst.i16 257
    v16 = iconst.i8 0
    v17 = iconst.i16 0
    v18 = iconst.i32 0
    v19 = iconst.i64 0
    v20 = uextend.i128 v19  ; v19 = 0
    stack_store v23, ss0
    stack_store v24, ss1
    stack_store v22, ss2
    v21 = call fn0(v2), stack_map=[i16 @ ss0+0, f32 @ ss1+0, i64x2 @ ss2+0]
    v24 -> v21
    brif v8, block1(v4), block1(v4)

block1(v14: i32x4):
    return v14, v14, v22, v14, v22, v23, v24, v25, v14, v14, v26, v27
}


; Note: the results in the below test cases are simply a placeholder and probably will be wrong

; run: u1:0(0x00000000000000000000000000000000, 0, 0.0, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0, 0, 0) == [0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0, 0.0, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000]

</details>

view this post on Zulip Wasmtime GitHub notifications bot (Jul 11 2024 at 18:11):

fitzgen commented on PR #8941:

Thanks Afonso!!

I'll take a look a little later today.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 12 2024 at 16:50):

fitzgen commented on PR #8941:

I have a fix, PR incoming.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 12 2024 at 16:58):

fitzgen commented on PR #8941:

I have a fix, PR incoming.

https://github.com/bytecodealliance/wasmtime/pull/8945

view this post on Zulip Wasmtime GitHub notifications bot (Jul 12 2024 at 17:00):

fitzgen commented on PR #8941:

I've been running cranelift-fuzzgen with this branch and my fix from that other PR for a little while and nothing else has turned up, so we can probably land this PR as soon as the other lands.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 12 2024 at 17:02):

fitzgen submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 12 2024 at 17:02):

fitzgen submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 12 2024 at 17:02):

fitzgen created PR review comment:

            let uses_stack_map = ty.bytes() <= 16 && self.u.arbitrary()?;

view this post on Zulip Wasmtime GitHub notifications bot (Jul 12 2024 at 17:03):

fitzgen submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 12 2024 at 17:03):

fitzgen created PR review comment:

Not sure if cranelift-fuzzgen will generate types larger than 16 bytes in the first place, but even if it doesn't, this is a good guard rail to have for future proofing.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 13 2024 at 19:25):

afonso360 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 13 2024 at 19:25):

afonso360 created PR review comment:

Not currently, but probably good to add this in!

view this post on Zulip Wasmtime GitHub notifications bot (Jul 13 2024 at 21:02):

afonso360 commented on PR #8941:

Running it locally seems to have run into another crash, this one quite a bit larger. It also doesn't seem to minimize well.

<details>
<summary>base64</summary>

/0DfRUooLS0tNEsASwBLS0sxDUt1MUs6/w0KS7//AMgh/4hbAy76HwGo/wL/LHv/fv9/KwD2ODg4ODhVN0I4ODgBAAATODgxAADvFv9A30VKMS0tLS0wSwBJAEtLC7kAS0tLDUtLDQL/v/8AyCGI2FsDLvofAaj/Av9Me3p+/38AAPY0NDgyNjGcnJycnJxenAAAAAAAAAAQAAAAC7kAS0sAAIEAgAgAEx8fHx/X4ODgHwAfHx8fHx8fHx8fHx8lH4j//w0DA9HR0dHR0dHR0dHR0dHRwtHRODg4GDAwMHIwMRM7AP8oAP8fRT7IyE0BKP8Cfv9b/3p/AAAALAHqAPr//5wB9wD/3/v7+/v7+wD2ODg4AQAAA//83P8oRT7IyE0AOwAFABcAAAAA8N0S3QMyAABiYmJiY2JiOhEREf4f3t7f4v8OHQAAAAAAFDQ0GjRHMCol7QAMDv////////8R/8vINADSKzQ1M7HNz8g7GwUAAW3/Kho0NGxsMQcAAAD+/v4BAQF57+pF///v6kVFRUUAgICAgICAAA7PAACTMJNFRUWf

</details>

<details>
<summary>Panic</summary>

Running: fuzz/artifacts/cranelift-fuzzgen/crash-64fe78830d244b9bce1bd3fbfa0e14cceff1242c
thread '<unnamed>' panicked at fuzz/fuzz_targets/cranelift-fuzzgen.rs:403:14:
called `Result::unwrap()` on an `Err` value: Compilation error: Verifier errors

Caused by:
    0: Verifier errors
    1: - inst263 (stack_store.i32 v178, ss6+4): uses value arg from non-dominating block3

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
==14905== ERROR: libFuzzer: deadly signal
NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.

</details>

<details>
<summary>Clif</summary>

;; Run test case

test interpret
test run
set opt_level=speed
set bb_padding_log2_minus_one=10
set enable_safepoints=true
set enable_llvm_abi_extensions=true
set unwind_info=false
set machine_code_cfg_info=true
target x86_64 has_sse3 has_ssse3 has_sse41 has_sse42 has_avx has_avx2 has_fma has_popcnt has_bmi1 has_bmi2 has_lzcnt

function u1:0(i8 sext, i8x16, i64 uext, i16 sext, i16x8, i32 sext, f32, f64, i16x8, i32x4, i16x8, i64x2, i128 sext, f64x2, i128, i128) tail {
    ss0 = explicit_slot 76, align = 512
    ss1 = explicit_slot 59, align = 32
    ss2 = explicit_slot 0, align = 2
    ss3 = explicit_slot 126, align = 512
    ss4 = explicit_slot 52, align = 256
    ss5 = explicit_slot 108, align = 32
    ss6 = explicit_slot 8, align = 4
    ss7 = explicit_slot 16, align = 8
    ss8 = explicit_slot 80, align = 16
    sig0 = (f32) -> f32 system_v
    sig1 = (f64) -> f64 system_v
    sig2 = (f32) -> f32 system_v
    sig3 = (f64) -> f64 system_v
    sig4 = (f32) -> f32 system_v
    sig5 = (f64) -> f64 system_v
    fn0 = %CeilF32 sig0
    fn1 = colocated %CeilF64 sig1
    fn2 = colocated %FloorF32 sig2
    fn3 = %FloorF64 sig3
    fn4 = %TruncF32 sig4
    fn5 = %TruncF64 sig5

block0(v0: i8, v1: i8x16, v2: i64, v3: i16, v4: i16x8, v5: i32, v6: f32, v7: f64, v8: i16x8, v9: i32x4, v10: i16x8, v11: i64x2, v12: i128, v13: f64x2, v14: i128, v15: i128):
    v32 = iconst.i8 0
    v33 = iconst.i16 0
    v34 = iconst.i32 0
    v35 = iconst.i64 0
    v36 = uextend.i128 v35  ; v35 = 0
    v37 = stack_addr.i64 ss4
    store notrap v36, v37
    v38 = stack_addr.i64 ss4+16
    store notrap v36, v38
    v39 = stack_addr.i64 ss4+32
    store notrap v36, v39
    v40 = stack_addr.i64 ss4+48
    store notrap v34, v40  ; v34 = 0
    v41 = stack_addr.i64 ss1
    store notrap heap v36, v41
    v42 = stack_addr.i64 ss1+16
    store notrap heap v36, v42
    v43 = stack_addr.i64 ss1+32
    store notrap heap v36, v43
    v44 = stack_addr.i64 ss1+48
    store notrap heap v35, v44  ; v35 = 0
    v45 = stack_addr.i64 ss1+56
    store notrap heap v33, v45  ; v33 = 0
    v46 = stack_addr.i64 ss1+58
    store notrap heap v32, v46  ; v32 = 0
    v47 = stack_addr.i64 ss0
    store notrap v36, v47
    v48 = stack_addr.i64 ss0+16
    store notrap v36, v48
    v49 = stack_addr.i64 ss0+32
    store notrap v36, v49
    v50 = stack_addr.i64 ss0+48
    store notrap v36, v50
    v51 = stack_addr.i64 ss0+64
    store notrap v35, v51  ; v35 = 0
    v52 = stack_addr.i64 ss0+72
    store notrap v34, v52  ; v34 = 0
    v53 = stack_addr.i64 ss5
    store notrap vmctx v36, v53
    v54 = stack_addr.i64 ss5+16
    store notrap vmctx v36, v54
    v55 = stack_addr.i64 ss5+32
    store notrap vmctx v36, v55
    v56 = stack_addr.i64 ss5+48
    store notrap vmctx v36, v56
    v57 = stack_addr.i64 ss5+64
    store notrap vmctx v36, v57
    v58 = stack_addr.i64 ss5+80
    store notrap vmctx v36, v58
    v59 = stack_addr.i64 ss5+96
    store notrap vmctx v35, v59  ; v35 = 0
    v60 = stack_addr.i64 ss5+104
    store notrap vmctx v34, v60  ; v34 = 0
    v61 = stack_addr.i64 ss3
    store notrap table v36, v61
    v62 = stack_addr.i64 ss3+16
    store notrap table v36, v62
    v63 = stack_addr.i64 ss3+32
    store notrap table v36, v63
    v64 = stack_addr.i64 ss3+48
    store notrap table v36, v64
    v65 = stack_addr.i64 ss3+64
    store notrap table v36, v65
    v66 = stack_addr.i64 ss3+80
    store notrap table v36, v66
    v67 = stack_addr.i64 ss3+96
    store notrap table v36, v67
    v68 = stack_addr.i64 ss3+112
    store notrap table v35, v68  ; v35 = 0
    v69 = stack_addr.i64 ss3+120
    store notrap table v34, v69  ; v34 = 0
    v70 = stack_addr.i64 ss3+124
    store notrap table v33, v70  ; v33 = 0
    v71 = stack_addr.i64 ss3
    v72 = load.i64x2 table v71+17
    v73 = stack_addr.i64 ss5+27
    v74 = sload8.i64 vmctx v73
    v75 = insertlane v9, v5, 0
    v76 = stack_addr.i64 ss0+69
    v77 = sload16.i32 v76+1
    v78 = icmp_imm uge v0, 168
    brif v78, block7, block6

block7:
    v79 = icmp_imm.i8 uge v0, 215
    brif v79, block9, block8

block9:
    v80 = icmp_imm.i8 eq v0, 250
    brif v80, block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block10

block10:
    v81 = icmp_imm.i8 uge v0, 215
    brif v81, block11, block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3)

block11:
    v82 = iadd_imm.i8 v0, -215
    v83 = uextend.i32 v82
    br_table v83, block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), [block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3)]

block8:
    v84 = icmp_imm.i8 uge v0, 185
    brif v84, block13, block12

block13:
    v85 = iadd_imm.i8 v0, -185
    v86 = uextend.i32 v85
    br_table v86, block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), [block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3)]

block12:
    v87 = icmp_imm.i8 eq v0, 168
    brif v87, block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3)

block6:
    v88 = icmp_imm.i8 uge v0, 91
    brif v88, block15, block14

block15:
    v89 = icmp_imm.i8 uge v0, 128
    brif v89, block17, block16

block17:
    v90 = iadd_imm.i8 v0, -128
    v91 = uextend.i32 v90
    br_table v91, block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), [block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3)]

block16:
    v92 = icmp_imm.i8 eq v0, 91
    brif v92, block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3)

block14:
    v93 = icmp_imm.i8 eq v0, 75
    brif v93, block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block18

block18:
    v94 = uextend.i32 v0
    br_table v94, block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), [block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block3(v77, v12, v75, v72, v7, v0, v4, v74, v6, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75, v72, v7, v0, v4, v3), block1(v74, v6, v12, v77, v75,
[message truncated]

view this post on Zulip Wasmtime GitHub notifications bot (Jul 13 2024 at 21:03):

afonso360 updated PR #8941.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 13 2024 at 21:05):

afonso360 has marked PR #8941 as ready for review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 13 2024 at 21:05):

afonso360 requested cfallin for a review on PR #8941.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 13 2024 at 21:05):

afonso360 requested wasmtime-compiler-reviewers for a review on PR #8941.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 20:11):

fitzgen commented on PR #8941:

Running it locally seems to have run into another crash, this one quite a bit larger. It also doesn't seem to minimize well.

Taking a look, thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 20:18):

fitzgen commented on PR #8941:

@afonso360 huh, that input doesn't fail on de29ce3598 for me. Will try fuzzing for a while.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 20:22):

afonso360 commented on PR #8941:

Oh, i pushed a new revision that changes the input format! You might want to force reset onto https://github.com/bytecodealliance/wasmtime/pull/8941/commits/635ea5789a1bad50af2695dcca937cf7c53b54cd

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 20:22):

afonso360 edited a comment on PR #8941:

Oh, I pushed a new revision that changes the input format! You might want to force reset onto https://github.com/bytecodealliance/wasmtime/pull/8941/commits/635ea5789a1bad50af2695dcca937cf7c53b54cd

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 20:23):

afonso360 edited a comment on PR #8941:

@fitzgen Oh, I pushed a new revision that changes the input format! You might want to force reset onto https://github.com/bytecodealliance/wasmtime/pull/8941/commits/635ea5789a1bad50af2695dcca937cf7c53b54cd

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 20:29):

fitzgen commented on PR #8941:

@fitzgen Oh, I pushed a new revision that changes the input format! You might want to force reset onto 635ea57

Huh. On top of 635ea5789a, I also don't get any fuzzing failures.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 20:46):

afonso360 commented on PR #8941:

That is super weird :thinking: Can you run md5sum on the input file? I was able to reproduce with 3cc2b287a4ea60cdb54e87640f0ff0e5.

Otherwise, I have no idea why this wouldn't reproduce.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 21:52):

fitzgen commented on PR #8941:

I'm indeed getting a different md5 sum, even when I re-create the file from the base64 again. Mind uploading the full input as an attachment?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 15 2024 at 22:14):

afonso360 commented on PR #8941:

Github doesn't seem to like files without extensions. Here's the original fuzz input
input.txt

view this post on Zulip Wasmtime GitHub notifications bot (Jul 22 2024 at 20:27):

fitzgen commented on PR #8941:

After cherry picking #8978 onto this branch, the fuzz input no longer fails. Running a bit longer locally to see if anything else turns up.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 23 2024 at 19:13):

fitzgen commented on PR #8941:

Found another bug with this fuzzer overnight, fix over in https://github.com/bytecodealliance/wasmtime/pull/9000

Continuing to run the fuzzer now.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 24 2024 at 16:09):

fitzgen commented on PR #8941:

Thought I was in the clear after running the fuzzer all day yesterday without issue, but I woke up to a new fuzz bug.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 24 2024 at 18:00):

fitzgen commented on PR #8941:

Thought I was in the clear after running the fuzzer all day yesterday without issue, but I woke up to a new fuzz bug.

Turns out this was actually unrelated to safepoints/stack maps, but generating them in fuzzgen made it more likely to produce the specific shape of code required to trigger a pre-existing bug. Fix in https://github.com/bytecodealliance/wasmtime/pull/9003

view this post on Zulip Wasmtime GitHub notifications bot (Jul 24 2024 at 18:10):

fitzgen commented on PR #8941:

At this point, I think we can go ahead and merge this PR and deal with any remaining issues as OSS-Fuzz finds them.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 24 2024 at 18:11):

fitzgen commented on PR #8941:

I'll enqueue this to merge after https://github.com/bytecodealliance/wasmtime/pull/9003 merges.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 25 2024 at 08:19):

afonso360 merged PR #8941.

Last updated: Dec 23 2024 at 12:05 UTC