<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 11, 2015 at 7:25 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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"><div class="gmail_extra"><div class="gmail_quote"><span><div>...</div></span><div>So if I'm seeing tens of thousands of distinct test files, that represents tens of thousands of distinct edges? </div></div></div></div></blockquote><div><br></div></span><div>In the extreme case -- yes.</div><div>However usually a single file covers more than one unique edge. </div><div>Also, if you are running the fuzzer in parallel (-jobs=N) some edges can be discovered many times. </div><span class=""><div>...</div></span></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div>With -fsanitize-coverage=indirect-calls it will also track indir call edges (uniq pairs of caller-callee). <br></div></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div></div></div></div></div></div></blockquote></span></div></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>Ok, I think the parallel jobs and unique caller/callee pairs must be where it got amped up a bit. I'm using "bb,indirect-calls,8bit-counters".</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div> save_minimized_corpus <span style="white-space:pre-wrap"> </span>0<span style="white-space:pre-wrap"> </span>If 1, the minimized corpus is saved into the first input directory</div></div><div>-------------<br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div></blockquote></span></div></div></div></blockquote><div><br></div></span><div>Ohh, ok. I think I misunderstood this to trying to minimize the size of the test case while still reproducing a crash. Similar to how afl-tmin works, I was thinking. I'll give this a try. </div><div><br></div><div>Should I only use this option periodically or can I run it this way all the time? Do we end up spending more execution time minimizing the corpus? Will it delete redundant test cases, including ones that were there before this test run started?</div></div></div></div></blockquote><div><br></div></span><div>You should only use this option if you want to store the minimized corpus somewhere, </div></div></div></div></blockquote><div><br></div><div>Ok, so I can do it periodically to prune the test corpus. That's great.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>or if the initial stage (between "#0 READ" and "#1331 INITED") takes too long. </div><div>Otherwise you should not bother since libFuzzer minimizes the corpus in memory on every run. </div><div>(minimization is done with a trivial greedy algorithm, not even close to really minimal solution, but good enough).</div><div>The output looks like this: </div><div><br></div><div><div>#0 READ cov 0 bits 0 units 1331 exec/s 0 </div></div><div>... </div><div><div>#1024 pulse cov 8043 bits 13474 units 1331 exec/s 256 </div><div>#1331 INITED cov 8050 bits 13689 units 594 exec/s 221 </div><div>#2048 pulse cov 8050 bits 13689 units 594 exec/s 341 </div></div><div><br></div><div>This means that the corpus on disk had 1331 units, they were read, shuffled, executed, and those that added coverage were chosen. </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div></span></div></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div><br></div><div>Hah! this means I've been misreading this line all along. My eyes zoomed in on "N exec/s" and I assumed that was the throughput (and I just ignored the "suffix" entry). So it's "cov X" / "bits Y" / "units Z" / "exec/s W" ? I guess the PCRE2 use case in the docs explains some of this -- I should've read this more closely.</div><div><br></div><div><br></div><div> ...</div><div>Aha, of course. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I run non-async-signal-safe code in the signal handler, bummer.</div><div>Let me try to fix this (no promises for a quick fix, I'll be out for a while). </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><font color="#888888"><div></div></font></span></div></div></blockquote></span></div></div></div></blockquote><div> </div><div>Ok, no problem. If you don't get around to it I can probably come up w/a fix.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">-Brian</div>
</div></div>