
<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 Feb 1, 2017, at 9:27 AM, Kostya Serebryany <<a href="mailto:kcc@google.com" class="">kcc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Feb 1, 2017 at 9:19 AM, Michael Kruse<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:llvmdev@meinersbur.de" target="_blank" class="">llvmdev@meinersbur.de</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><span class="">2017-02-01 18:07 GMT+01:00 Kostya Serebryany <<a href="mailto:kcc@google.com" class="">kcc@google.com</a>>:<br class="">> Yes, I used to run clang-fuzzer and clang-format-fuzzer on this bot, but not<br class="">> any more.<br class="">> The reason is simple -- the bot was always red (well, orange) and the bugs<br class="">> were never fixed.<br class="">><br class="">> Currently we run clang-fuzzer (but not clang-format-fuzzer) on our internal<br class="">> fuzzing infra<br class="">> and Richard has fixed at least one bug found this way.<br class="">><span class="Apple-converted-space"> </span><a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=291030" rel="noreferrer" target="_blank" class="">http://llvm.org/viewvc/llvm-<wbr class="">project?view=revision&<wbr class="">revision=291030</a><br class="">><br class="">> My llvm fuzzing bot was pretty naive and simple.<br class="">> If we want proper continuous fuzzing for parts of LLVM we either need to<br class="">> build a separate "real" continuous fuzzing process,<br class="">> or use an existing one. Luckily, there is one :)<br class="">> As a pilot I've recently added the cxa_demangler_fuzzer to OSS-Fuzz:<br class="">><span class="Apple-converted-space"> </span><a href="https://github.com/google/oss-fuzz/tree/master/projects/llvm_libcxxabi" rel="noreferrer" target="_blank" class="">https://github.com/google/oss-<wbr class="">fuzz/tree/master/projects/<wbr class="">llvm_libcxxabi</a><br class="">> It even found one bug which Mehdi already fixed!<br class="">><span class="Apple-converted-space"> </span><a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=293330" rel="noreferrer" target="_blank" class="">http://llvm.org/viewvc/llvm-<wbr class="">project?view=revision&<wbr class="">revision=293330</a><br class="">> The bug report itself will become public in ~4 days:<br class="">><span class="Apple-converted-space"> </span><a href="https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=370" rel="noreferrer" target="_blank" class="">https://bugs.chromium.org/p/<wbr class="">oss-fuzz/issues/detail?id=370</a><br class=""><br class=""></span>Thanks for the explanation.<br class=""><span class=""><br class=""><br class=""><br class="">>> > Another (obvious?) fuzzing candidate would be the LLVM's bitcode<br class="">>> > reader. I ran afl-fuzz on it and it found lots of failed assertions<br class="">>> > within seconds. Isn't fuzzing done on a regular basis as [1] suggests<br class="">>> > should be done? Should I report the crashes found by it?<br class="">>><br class="">>> The bitcode reader is known to not be robust against malformed inputs.<br class="">><br class="">><br class="">> Yes, I afraid the bitcode reader (as some other parts of LLVM) are not<br class="">> robust enough to withstand fuzzing. :(<br class="">> Note that if we want to use libFuzzer (which is an in-process fuzzer) the<br class="">> target should not assert/abort/exit on any input (if it's not a bug).<br class=""><br class=""></span>Is there any incentive to change that?<span class="Apple-converted-space"> </span></blockquote><div class=""><br class=""></div><div class="">Not that I know of.</div><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">A google Summer of Code project maybe?<br class=""></blockquote><div class=""><br class=""></div><div class="">Maybe. </div><div class="">The bottleneck is not bug finding, but bug fixing, which sometimes may require large changes. </div><div class="">And doing code review for such changes might be more work than just making them. </div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">For the bitcode for example, I wouldn’t expect it to be large changes that would be complicated to review. However these are still tedious bugs to fix.</div><div class="">About a GSOC, my own personal opinion is that we should try to give interesting / fun projects to student and not use them as cheap labor to fix the small bugs and issues we’re not able to prioritize ourself.</div><div class=""><br class=""></div><div class="">My 2 cents :)</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div></body></html>