how to get generated test cases? · cranelift

Hi, I'm trying to fuzz cranelift using cargo fuzz run cranelift-fuzzgen, but it gets stuck after printing:

INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 155173815
INFO: Loaded 1 modules   (1799139 inline 8-bit counters): 1799139 [0x55c390b711b0, 0x55c390d28593),
INFO: Loaded 1 PC tables (1799139 PCs): 1799139 [0x55c390d28598,0x55c39289c3c8),
INFO:        0 files found in /home/obfuscator/wasmtime/fuzz/corpus/cranelift-fuzzgen
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: A corpus is not provided, starting from an empty corpus
#2      INITED exec/s: 0 rss: 126Mb
WARNING: no interesting inputs were found so far. Is the code instrumented for coverage?
This may also happen if the target rejected all inputs we tried so far

The command just hangs after that warning with no visible progress. Any help would be appreciated!

Alex Crichton (Jun 17 2025 at 14:34):

The general documentation for fuzzing in Rust is found here which might be good to peruse, that goes over folder structure and such of where artifacts are located. By default cargo fuzz run cranelift-fuzzgen will run the fuzzer infinitely until a crash happens, and the crash is recorded in the fuzz/* directory inside there

ping (Jun 17 2025 at 14:46):

I added an unreachable!() statement at this location, then ran: cargo fuzz run cranelift-fuzzgen. And I get the same output as before with no panic. Does this mean the fuzz target's code isn't being executed at all?

Alex Crichton (Jun 17 2025 at 14:56):

yeah that definitely looks like something funky is going on, I'm testing out that myself and seeing what happens.

In the meantime, what is cargo fuzz --version and what version of Rust are you using?

Alex Crichton (Jun 17 2025 at 14:57):

for me it's cargo-fuzz 0.12.0 and rustc 1.89.0-nightly (ccf3198de 2025-06-05)

ping (Jun 17 2025 at 14:57):

Alex Crichton (Jun 17 2025 at 14:59):

Alex Crichton (Jun 17 2025 at 15:02):

ping (Jun 17 2025 at 15:03):

Thank you for investigating this. I'd be truly grateful if this could be prioritized for a fix.

Alex Crichton (Jun 17 2025 at 15:07):

Fix Cranelift-native fuzzers by alexcrichton · Pull Request #11062 · bytecodealliance/wasmtime

This commit fixes a typo mistake from #10588 where the option specified there was actually invalid. This error got covered up by accident when generating the fuzz test case, however, meaning that t...

ping (Jun 17 2025 at 15:08):

Alex Crichton (Jun 17 2025 at 15:10):

FWIW I'd recommend fuzzing with --sanitizer none as it makes fuzzing go much faster and we don't get too much benefit from the default ASAN integration

ping (Jun 17 2025 at 15:11):

ping (Jun 20 2025 at 07:00):

@Alex Crichton Hi, I’ve saved the generated test cases, but I noticed an issue: most of them contain functions similar to the following pattern:

function u1:0() fast {
    ss0 = explicit_slot 58, align = 32
    ss1 = explicit_slot 18
    ss2 = explicit_slot 0
    sig0 = (i16x8, i128 sext, i16x8, i16x8, i64x2, f64, i8 sext) -> i16x8 system_v
    sig1 = (f32) -> f32 system_v
    sig2 = (f64) -> f64 system_v
    sig3 = (f32) -> f32 system_v
    sig4 = (f64) -> f64 system_v
    sig5 = (f32) -> f32 system_v
    sig6 = (f64) -> f64 system_v
    fn0 = u1:1 sig0
    fn1 = %CeilF32 sig1
    fn2 = %CeilF64 sig2
    fn3 = colocated %FloorF32 sig3
    fn4 = colocated %FloorF64 sig4
    fn5 = %TruncF32 sig5
    fn6 = %TruncF64 sig6

block0:
    v0 = iconst.i8 0
    v1 = iconst.i16 0
    v2 = iconst.i32 0
    v3 = iconst.i64 0
    v4 = uextend.i128 v3  ; v3 = 0
    v5 = stack_addr.i64 ss1
    store notrap v4, v5
    v6 = stack_addr.i64 ss1+16
    store notrap v1, v6  ; v1 = 0
    v7 = stack_addr.i64 ss0
    store notrap heap v4, v7
    v8 = stack_addr.i64 ss0+16
    store notrap heap v4, v8
    v9 = stack_addr.i64 ss0+32
    store notrap heap v4, v9
    v10 = stack_addr.i64 ss0+48
    store notrap heap v3, v10  ; v3 = 0
    v11 = stack_addr.i64 ss0+56
    store notrap heap v1, v11  ; v1 = 0
    return
}

Alex Crichton (Jun 20 2025 at 14:06):

Ah sorry I'm not too familar with cranelift-fuzzgen's implementation. I do believe we test some cases against the host but it's not necessarily engineered to ensure all results are compatible against the hosts. As a fuzz-generated program some are probably more amenable to detecting differences than others

ping (Jun 20 2025 at 14:11):

OK, thank you for your response. I've gone through it again and it seems that there might be some issues with my operation. Now the generated IR test cases are a bit more complex.

Afonso Bordado (Jun 20 2025 at 18:08):

Not really, It's just that it's really simple to generate an function that contains no input or output parameters, and produces no real instructions that use those.

That function essentially just sets up the stack area for use by the function, and exists, it's one of the simplest functions possible.

IIRC we have a few knobs you can tweak. The first one is the number of input / output arguments. Due to the way the fuzzer is built, the more variables it has available, the easier it is to pick an instruction that does something. The second one is that you can force it to always produce at least 1 "real" instruction

I don't remember off the top of my head what these parameters were, but they were there.

Afonso Bordado (Jun 20 2025 at 18:09):

Here they are. You can tweak those 3 parameters and it should produce slightly larger functions

Stream: cranelift

Topic: how to get generated test cases?

ping (Jun 17 2025 at 14:19):