similar to: [Fuzzer] Test failure on Linux x86-64

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

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

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:

Hello again, I had hoped that rc4 would be the last one, but I wanted to pick up one more fix, so here we go. Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the release branch at 35627038123. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc5 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc5 If nothing new comes up, I plan to tag

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

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

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

On Tue, Aug 22, 2017 at 4:34 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, Aug 22, 2017 at 4:21 PM, George Karpenkov <ekarpenkov at apple.com> > wrote: > >> Hi, >> >> As a part of a recent move of libFuzzer from LLVM to compiler-rt I am >> looking into updating the build code >> for the libraries which use libFuzzer.

Justin, I haven't seen this before. I suspect it is because of line-tables-only. Can you try it with full debug info? On Tue, Mar 7, 2017 at 12:36 PM Kostya Serebryany <kcc at google.com> wrote: > +aizatsky > > On Tue, Mar 7, 2017 at 12:34 PM, Justin Bogner <mail at justinbogner.com> > wrote: > > I'm working on a fuzzer using libFuzzer and I wanted to take

While playing with sanitizer in a downstream project, I found out this. /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst));

I'm working on a fuzzer using libFuzzer and I wanted to take a look at how my coverage was doing, as per the instructions here: http://llvm.org/docs/LibFuzzer.html#how-good-is-my-fuzzer First of all, I suspect the instructions there are out of date, but passing -dump_coverage=1 to the binary rather than setting ASAN_OPTIONS generated a .sancov file for me. However, when I inspect this

I'll need more details then. Maybe you can share the binary & its .sancov file? Or if you have a way to reproduce it? On Tue, Mar 7, 2017 at 1:23 PM Kostya Serebryany <kcc at google.com> wrote: > On Tue, Mar 7, 2017 at 12:50 PM, Mike Aizatsky <aizatsky at google.com> > wrote: > > Justin, > > I haven't seen this before. I suspect it is because of

It worked in August. Last time I’ve asked (again, in August) someone did seem to care, but it is inevitable it would bitrot if it’s not built in any of the bots. George > On May 4, 2018, at 2:53 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > While playing with sanitizer in a downstream project, I found out this. > >

Thank you. I went ahead with a speculative fix in r331568. I'm not familiar _at all_ with the tool, so, although the fix was straightforward, another pair of eyes from somebody familiar with the tool would be appreciated. On Fri, May 4, 2018 at 5:10 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > It worked in August. > Last time I’ve asked (again, in August) someone did

On Fri, Aug 25, 2017 at 8:51 AM, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > (removed my @imgtec.com address since it no longer exists) > > Sorry for the slow reply, it's a busy time for me right now. > > > On 23 Aug 2017, at 00:21, George Karpenkov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > As a

Hi, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have tried to compile llvm-mc-assemble-fuzzer, and llvm-mc-disassemble-fuzzer, and I couldn’t build either of those. For the first one, the reason is that it refers to a nonexistent enum, and for the second one I believe the reason is that it

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