[llvm-dev] -sanitizer-coverage-prune-blocks=true and LibFuzzer
Jonas Wagner via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 20 08:00:59 PDT 2016
Hello LLVM devs,
I'm running lots of experiments with LibFuzzer these days -- it's an
I've noticed something weird while examining the effect of various coverage
options: for one of my benchmarks, the fuzzer was achieving a higher total
coverage before April 2016, when -sanitizer-coverage-prune-blocks became
true by default (commit
Here are the numbers from running the fuzzer with different options for a
fixed amount of time.
#units #blocks #bits options
492 447 1666 -fsanitize-coverage=edge,indirect-calls,8bit-counters
135 447 754 -fsanitize-coverage=edge -mllvm
58 103 185
135 447 754 -fsanitize-coverage=edge
Here, units is the number of test cases generated, blocks is the number of
basic blocks covered (as measured by replaying the corpus using the
-sanitizer-coverage-prune-blocks=false version), and bits is the number of
bits from the 8bit-counters that were seen.
The outlier is the case where I use 8bit-counters and set
-sanitizer-coverage-prune-blocks to true. There are two things I don't
understand: (1) why can the 8bit-counters perform worse than using edge
coverage only, and (2) why does -sanitizer-coverage-prune-blocks affect the
result so much?
If needed, I can provide scripts to reproduce this (it's a bit of work to
clean them up, though). But maybe someone already has an idea why this
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev