Open nbigaouette opened 2 years ago
This appears to be related to -Cpanic=abort
panic strategy.
I'm not sure why we went with the -Cpanic=abort
approach; that was already in place before I started hacking on any of this stuff. Maybe someone else who remembers why it is like this can share?
It seems like using catch_unwind
inside the fuzz_target!
macro's expanded code would be more flexible and allow for users to catch+handle irrelevant panics inside the fuzz target.
AIUI the fuzzer works better if panics lead to immediate aborts since there's less logic to trace. But I'm not quite sure if there is a major difference.
I recall it being much better in a sense that it gives libfuzzer an opportunity to see unique crashes easier. Or at least that was the case back when I first MVPd the thing.
I recall it being much better in a sense that it gives libfuzzer an opportunity to see unique crashes easier. Or at least that was the case back when I first MVPd the thing.
This makes a ton of sense, since tools like oss-fuzz will ~essentially use only the crashing stack trace to differentiate bugs, AFAIK.
I wonder if we can make -Cpanic=abort
a CLI flag in cargo fuzz
? Would require some cooperation in libfuzzer-sys
too for whether to set the panic hook or not, probably with env vars like our other points of cooperation.
Yeah I think the solution here is to have an on by default option
I wrap a function that I know is buggy into a
std::panic::catch_unwind()
so that when it panics my own code does not. I can then gracefully handle the error.Unfortunately, libfuzzer still detects this as an error and stops.
Here's an example fuzzing target:
Where the file
fuzz/artifacts/issue/minimized-from-ac85e832d98dd32e68baaafa21973abcb7a73101
contains a single byte:0xF3
(243).Can we instruct libfuzzer to not bother with these kinds of errors?
Thanks!