similar to: [LLVMdev] Building the fuzzer library

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

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

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

On Thu, Sep 3, 2015 at 6:25 PM, Kostya Serebryany <kcc at google.com> wrote: > Not sure I understood this correctly. > Example? I've made a Postgres module which is dynamically loaded by Postgres as a shared library from which I can call the fuzzer on the SQL function of my choice. Postgres has enough meta information about the functions that I think the eventual interface might

I'm fairly sure your compiler (or rather linker) errors are coming from the fact that you are not linking to the C++ runtime library. Use `clang++ -std=c++11 *.o`, and I'm reasonably sure it will do what you want. -- Mats On 3 September 2015 at 12:26, Greg Stark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Aug 30, 2015 at 3:30 PM, Greg Stark <stark at

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

On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > On Jul 12, 2017, at 11:01 AM, Kostya Serebryany <kcc at google.com> wrote: > One question: will it make sense to *copy* the code to the new location, > work on it, then delete the code from the old location, > instead of doing a move in a single commit? > I don't expect any

(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

George Karpenkov <ekarpenkov at apple.com> writes: > Should -DCMAKE_CXX_COMPILER be also specified? CMake is smart enough to infer that from C_COMPILER: % grep CMAKE_CXX_COMPILER CMakeCache.txt CMAKE_CXX_COMPILER:FILEPATH=/Users/bogner/llvm-lkgc/bin/clang++ >> On Aug 24, 2017, at 11:29 AM, Justin Bogner <mail at justinbogner.com> wrote: >> >> (kcc, george:

> On May 10, 2017, at 4:43 PM, George Karpenkov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Actually, there’s another problem we have missed: libraries under `build/lib` are not installed into toolchain > on mac os (and neither on linux, I would suppose). Actually that isn't accurate. By default we don't install the LLVM libraries, but that is completely

On Tue, Jul 11, 2017 at 7:02 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > I’ve submitted a WIP PR: https://reviews.llvm.org/D35288 > Thanks for working in this! One question: will it make sense to *copy* the code to the new location, work on it, then delete the code from the old location, instead of doing a move in a single commit? I don't expect any dramatic changes

On Sat, Sep 5, 2015 at 11:50 AM, Greg Stark <stark at mit.edu> wrote: > On Sat, Sep 5, 2015 at 6:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > This is more like a limitation of asan, not libFuzzer. > > By design, asan does not recover from the first crash. > > This feature has been criticized quite a lot, but I am still convinced > this >

On Wed, Jul 12, 2017 at 11:54 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > On Jul 12, 2017, at 11:34 AM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov <ekarpenkov at apple.com> > wrote: > >> >> On Jul 12, 2017, at 11:01 AM, Kostya Serebryany <kcc at google.com> wrote:

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

+ Chandler, Danny, We are considering to move the libFuzzer code from llvm to compiler-rt, and that implies a license change. Will it be sufficient to do the following? * e-mail to all contributors (a short list, below) asking for their consent * remove any code for which we did not get consent in, say, 1 week. (BTW, this list is actually much shorter, I recognize many of these as belonging

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

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: >