search for: fuzzers

Hi, This started as an off hand comment in [1] but this appears to be a real issue so I'm moving the discussion to the mailing list. In r270942 the time taken to run LibFuzzer's test became noticeably longer. I am building on * Arch Linux (4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux) * I am building libFuzzer and running its tests like so ```

Reproduced, should be easy to fix. Will do it. And thanks for noticing, on my machine this fails very fast and the test passes because it sees everything it wants to see. --kcc On Fri, May 27, 2016 at 6:18 PM, Dan Liew <dan at su-root.co.uk> wrote: > Hi, > > This started as an off hand comment in [1] but this appears to be a > real issue so I'm moving the discussion to the

Kostya, I think I've found what looks like a reproducible bug in libFuzzer. The code under test is built with ASan and the first ASan CHECK failure shows fuzzer in the stack trace. (see below) One of the factors that may be unique in my testing is that each iteration can take a very long time to execute (tens or hundreds of seconds). Let me know if you need more info, I think it

Continuing my quixotic effort to get 'check-all' clean, I am seeing a Fuzzer failure on x86-64 Linux. Do any builders run fuzzer tests? FAIL: libFuzzer :: value-profile-mem.test (103 of 103) ******************** TEST 'libFuzzer :: value-profile-mem.test' FAILED ******************** Script: -- : 'RUN: at line 4'; /build/x86_64/./bin/clang --driver-mode=g++ -std=c++11

> > > I'd like llvm-isel-fuzzer to be added once its committed consider it done (once it's there) > (which should > be as soon as LLVM fuzzers work in release builds again). One potential > issue is that llvm-isel-fuzzer is more of a collection of fuzzers, and > it needs some arguments to run (ie, to choose the backend). > I have the same problem with clang-proto-fuzzer, which uses the same approach with flags as llvm-isel-fuzze...

FWIW I think that one was always flaky. > On Jan 4, 2019, at 2:53 PM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +Matt Morehouse <mailto:mascasa at google.com> > > On Fri, Jan 4, 2019 at 11:43 AM David Greene via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Continuing my quixotic effort

I decided to try out the fuzzer library and clang-fuzzer, but it doesn't seem to build for me. From the cmake files, I was pretty sure all I need to do is set -DLLVM_USE_SANITIZE_COVERAGE=ON, but with this I get a number of link errors for "lib/Fuzzer/test/LLVMFuzzer-CounterTest", for example: lib/libLLVMFuzzer.a(FuzzerLoop.cpp.o): In function `SetDeathCallback':

Kostya, Here's the git repo: https://bitbucket.org/ebadf/fuzzpy I've only tested it on arm7 and x86_64 linux, I expect there's a good chance it may not work on other OSs. If you can build it successfully ("./build.sh", requires clang and clang++ in your path), then you should run the "testemail" case like so: while true; do ITERS=1000 ./run.sh

Ah, yes -- you need to clone with --recursive. I will try the workaround though. On Dec 3, 2015 1:12 PM, "Kostya Serebryany" <kcc at google.com> wrote: > > > On Wed, Dec 2, 2015 at 7:17 PM, Brian Cain <brian.cain at gmail.com> wrote: > >> Kostya, >> >> Here's the git repo: https://bitbucket.org/ebadf/fuzzpy >> >> I've only

Done. r271095 On Fri, May 27, 2016 at 7:55 PM, Kostya Serebryany <kcc at google.com> wrote: > Reproduced, should be easy to fix. Will do it. > And thanks for noticing, on my machine this fails very fast and the test > passes because it sees everything it wants to see. > > --kcc > > On Fri, May 27, 2016 at 6:18 PM, Dan Liew <dan at su-root.co.uk> wrote: >

(kcc, george: sorry for the re-send, the first was from a non-list email address) My configuration for building the fuzzers in the LLVM tree doesn't seem to work any more (possibly as of moving libFuzzer to compiler-rt, but there have been a few other changes in the last week or so that may be related). I'm building with a fresh top-of-tree clang and setting -DLLVM_USE_SANITIZER=Address and -DLLVM_USE_SANITIZE_...

...LEPATH=/Users/bogner/llvm-lkgc/bin/clang++ >> On Aug 24, 2017, at 11:29 AM, Justin Bogner <mail at justinbogner.com> wrote: >> >> (kcc, george: sorry for the re-send, the first was from a non-list email >> address) >> >> My configuration for building the fuzzers in the LLVM tree doesn't seem to >> work any more (possibly as of moving libFuzzer to compiler-rt, but there >> have been a few other changes in the last week or so that may be related). >> >> I'm building with a fresh top-of-tree clang and setting >> -DLLVM_U...

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

On Mon, Aug 10, 2015 at 8:08 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Mon, Aug 10, 2015 at 5:53 PM, Brian Cain via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> First off, thanks -- this is a pretty great library and it feels like I'm >> learning a lot. >> > > Thanks! > > >> I'm getting some

...egression tests). > This will require us to tweak the cmake machinery to allow building fuzz > target with regular flags (no coverage). > 2. There should also be a bot that actually runs continuous fuzzing. > Our buildbots are not suitable for this, so I was planing to add the llvm > fuzzers to OSS-Fuzz (https://github.com/google/oss-fuzz) > We already run the cxa_demangler fuzzer there with quite a bit of success. > clang-fuzzer is now running on oss-fuzz, and here are two trophies so far: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3134 ASSERT: ParmVarDeclBits.Scop...

Hello List, I'm currently writing my own little optimization pass (on LLVM 6.0) and considered it a neat idea to fuzz it using llvm-opt-fuzzer, which in theory should be a ready-made tool for such jobs as far as I can tell, potentially helping me to find UB and Address issues in my pass. So I went ahead and followed the instructions in the build manual [1] to build LLVM's llvm-opt-fuzzer

So I was curious to start using the libFuzzer, but trying to follow along I got the following error: clang++ -fsanitize=address -fsanitize-coverage=edge test_fuzzer.cc Fuzzer*.o Undefined symbols for architecture x86_64: "_dfsan_create_label", referenced from: fuzzer::TraceState::DFSanCmpCallback(unsigned long, unsigned long, unsigned long, unsigned long long, unsigned long

...being done - how else did it work before? >> On Aug 24, 2017, at 11:29 AM, Justin Bogner <mail at justinbogner.com> wrote: >> >> (kcc, george: sorry for the re-send, the first was from a non-list email >> address) >> >> My configuration for building the fuzzers in the LLVM tree doesn't seem to >> work any more (possibly as of moving libFuzzer to compiler-rt, but there >> have been a few other changes in the last week or so that may be related). >> >> I'm building with a fresh top-of-tree clang and setting >> -DLLVM_U...

...d they? On Mac?) so I thought everything is ok. >>>> >> >>>> >> >>>> >> For tests we never compile the tested target with -O3 (and that >>>> wouldn’t >>>> >> be sufficient), >>>> >> and for testing fuzzers I was always building them in debug >>>> >> >>>> >> Yea, we need to make sure the pc-tables are not stripped (this is a >>>> >> separate section with globals). >>>> >> (I still haven't documented pc-tables, will do soon) &g...

...ing. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for testing fuzzers I was always building them in debug > Yea, we need to make sure the pc-tables are not stripped (this is a separate section with globals). > (I still haven't documented pc-tables, will do soon) > Do you know what's the analog of Wl,-dead_strip on Linux? Apparently -Wl,—gc-secti...