<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 21, 2016, at 9:36 AM, Kostya Serebryany via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Exciting! <div class=""><br class=""></div><div class=""><div class=""><span style="" class="">(btw, I'd prefer </span><font class=""><a href="mailto:libfuzzer@googlegroups.com" class="">libfuzzer@googlegroups.com</a> for such discussions, please start new topics there)</font></div></div></div></div></blockquote><div><br class=""></div><div>You mean a LLVM library has a separate mailing-list? Why?</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I can reproduce this too, but if i either increase <span style="" class="">FUZZER_TESTING_SECONDS to 600 or change seed=1 to seed=2 the problem is gone. </span></div><div class=""><span style="" class="">Looks like one of the binaries got simply unlucky with a particular seed. </span></div><div class=""><span style="" class="">You can observe it like this: </span></div><div class=""><pre style="" class="">for S in 1 2 3 4 5 6; do ./target-asan-8bit-prune-build/fuzzer -seed=$S -runs=10000000 2>&1 | grep DONE & done </pre><pre style="" class=""><pre style="top: -99px;" class="">#10000000 DONE cov: 60 bits: 91 indir: 1 units: 59 exec/s: 625000
#10000000 DONE cov: 60 bits: 91 indir: 1 units: 57 exec/s: 588235
#10000000 DONE cov: 253 bits: 901 indir: 12 units: 467 exec/s: 526315
#10000000 DONE cov: 63 bits: 95 indir: 1 units: 64 exec/s: 476190
#10000000 DONE cov: 252 bits: 923 indir: 12 units: 491 exec/s: 454545
#10000000 DONE cov: 253 bits: 880 indir: 12 units: 471 exec/s: 384615</pre></pre></div><div class=""><pre style="" class=""><br class=""></pre><pre style="" class="">Similar things happen with other binaries: </pre><pre style="" class="">for S in 1 2 3 4 5 6; do ./target-asan-8bit-nopru-build/fuzzer -seed=$S -runs=10000000 2>&1 | grep DONE & done</pre><pre style="" class=""><pre style="top: -99px;" class="">#10000000 DONE cov: 103 bits: 190 indir: 1 units: 62 exec/s: 526315
#10000000 DONE cov: 443 bits: 1730 indir: 12 units: 529 exec/s: 357142
#10000000 DONE cov: 443 bits: 1695 indir: 12 units: 509 exec/s: 344827
#10000000 DONE cov: 443 bits: 1682 indir: 12 units: 500 exec/s: 333333
#10000000 DONE cov: 444 bits: 1675 indir: 12 units: 501 exec/s: 277777
#10000000 DONE cov: 401 bits: 1443 indir: 12 units: 341 exec/s: 263157</pre></pre></div><div class=""><span style="" class=""><br class=""></span></div><div class=""><span style="" class="">I've also tried building with trace-pc-guard (the new thing) and results are similar. </span></div><div class=""><pre style="" class=""><pre style="top: -99px;" class="">name cov bits execs execs_per_sec units actual_cov actual_bits
asan-8bit-nopru 401 1443 19790806 324439 340 401 1441
asan-8bit-prune 256 897 26528866 434899 485 447 1651
asan-edge-nopru 447 0 35589496 583434 137 447 719
asan-edge-prune 256 0 37576436 616007 137 447 719
asan-trac-nopru 401 1443 12566606 206009 340 401 1441
asan-trac-prune 256 891 16295346 267136 480 447 1640</pre></pre></div><div class=""><br class=""></div><div class="">Conclusions: </div><div class="">* testing a fuzzing engine is not trivial :( </div><div class="">* testing it on a very short run with a single seed may be misleading</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">BTW, I am also looking into more automation of libFuzzer testing.</div><div class="">With trace-pc-guard we now have libFuzzer's flag -print_coverage=1 that will print all the covered lines. </div><div class="">My hope is that this feature can be used for more detailed analysis of coverage differences. </div><div class=""><br class=""></div><div class="">--kcc </div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Sep 21, 2016 at 6:00 AM, Jonas Wagner <span dir="ltr" class=""><<a href="mailto:jonas.wagner@epfl.ch" target="_blank" class="">jonas.wagner@epfl.ch</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class=""><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Is this reproducible? </div><div class="">Fuzzing is a probabilistic business and one or even two runs don't prove much. </div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><span style="line-height:1.5" class=""></span></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I've reproduced the behavior on two different machines. Attached is a script to do so. To use the script,</div><div class=""><br class=""></div><div class="">- create an empty folder and copy both prune-blocks.sh and ff-http-parser.sh in there</div><div class=""><span style="line-height:1.5" class="">- ensure clang and clang++ are in your $PATH</span></div><div class="">- cd /path/to/prune-blocks.sh</div><div class="">- ./prune-blocks.sh</div><div class=""><br class=""></div><div class="">Let me know how it goes.</div><span class=""><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><span style="line-height:1.5" class="">Note that I am going to change all of these coverage options soon. </span><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">The new thing will be <a href="http://clang.llvm.org/docs/SanitizerCoverage.html#tracing-pcs-with-guards" target="_blank" class="">http://clang.llvm.org/docs/<wbr class="">SanitizerCoverage.html#<wbr class="">tracing-pcs-with-guards</a></div><div class="">It will replace regular (boolean) and 8-bit-counters coverage. </div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Yay, sounds exciting! I've done a couple experiments to measure the performance and effect of the different coverage options in the recent past. If you're interested, I'd be happy to discuss off-list; simply send me an email.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Jonas</div></div></div></div>
</blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>