search

thepudds / fzgen

Auto-gen Go fuzzing wrappers from normal code. Finds buggy call sequences, including data races & deadlocks. Supports rich signature types.
Apache License 2.0
105 stars 5 forks source link

Is `export FZDEBUG=repro=1` only useful for chained fuzzers? #18

Open jasikpark opened 2 years ago

jasikpark commented 2 years ago

When running the reproduction with a regular generated fuzzer, I only get a backtrace, rather than having the full code used like shown in the README / that I was able to replicate in the parallel+chain tutorial in the readme

func Fuzz_TimerWheel_NewTimerWheel(f *testing.F) {
    f.Fuzz(func(t *testing.T, data []byte) {
        var min time.Duration
        var max time.Duration
        fz := fuzzer.NewFuzzer(data)
        fz.Fill(&min, &max)

        NewTimerWheel(min, max)
    })
}

doesn't produce a length test description.. I suppose maybe it wouldn't, since presumably it's just a single function call?

thepudds commented 1 year ago

Hi @jasikpark, thank you for filing this.

Yes, right now setting the environment variable FZDEBUG=repro=1 only is helpful for chained functions (e.g., as generated by fzgen -chain), such as this example in the README.

As you implied, that is where it is most useful, especially given there can be a potentially intricate series of calls needed to produce bad behavior.

However, it would be nice to also do something minimal even if it is not a chained function, so we can keep this issue open to track that.