similar to: A Prototype to Track Input Read for Sparse File Fuzzing

r247321 refactors the code so that it should build on Mac. I haven't actually tested it on Mac -- so please help me and send follow up patches if needed. check-fuzzer will still fail because some of the libFuzzer tests require dfsan. I'd use some help from someone with a Mac to modify lib/Fuzzer/test/CMakeLists.txt so that it does not run dfsan-dependent tests on Mac. Thanks, --kcc On

On Sun, Aug 30, 2015 at 9:11 AM, Brian Cain via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Sun, Aug 30, 2015 at 9:30 AM, Greg Stark via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I have a project I want to do based on Libfuzzer. Is there a separate >> list for it or should I bring up any ideas for it here? >> >> No separate

libFuzzer is Clang's fuzzer, and alternative to using AFL: https://llvm.org/docs/LibFuzzer.html I implemented an alternative method of fuzzing for libnbd earlier today and it's pretty simple: https://github.com/libguestfs/libnbd/commit/c19a6fbae9a21a7d4693418706c59e81ed256875 However it's considerably more difficult to use libFuzzer with non-library code -- in this case nbdkit.

v1 was here: https://www.redhat.com/archives/libguestfs/2019-November/msg00003.html This version depends on: https://www.redhat.com/archives/libguestfs/2019-November/msg00004.html and this series: https://www.redhat.com/archives/libguestfs/2019-November/msg00009.html The delta has been reduced slightly because of changes made possible by cleaning up and fixing the quit path in nbdkit. It's

Kostya, I took a quick stab at patching libFuzzer for Apple, but so far I'm thinking something else is incorrect. Patch is attached but when I went to reproduce the examples, the toy example went fine, but with PCRE and Heartbleed I noticed the coverage statistics were pretty poor, and didn't find anything. Admittedly I moved onto Heartbleed pretty quickly so PCRE probably isn't the

FWIW see also http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043301.html As far as I understand DFSan functionality isn't required for libFuzzer to work, so it should be safe to disable DFSan support on Mac. On Wed, Jul 8, 2015 at 7:45 AM, Kostya Serebryany <kcc at google.com> wrote: > +pcc , glider > > On Mon, Jul 6, 2015 at 12:59 PM, Juan Ceasar <juan.d.ceasar at

On Wed, Feb 1, 2017 at 8:45 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Feb 1, 2017, at 8:34 AM, Michael Kruse via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > The blog entry [1] suggest that one of the buildbots constantly fuzzes > > clang and clang-format. However, the actual bot [2] only tests the

I am working of using libfuzzer and asan to test out a third-party library. As demonstrated in the tutorial, I wrote a fuzz target to fuzz a specific function in the library. The fuzz target is then linked to the library and compiles clean and I do see some tests generated by the fuzzer. However, I have some questions regarding the "right" way to go about doing this. I have doubts that

I have a project I want to do based on Libfuzzer. Is there a separate list for it or should I bring up any ideas for it here? What I have in mind is to fuzz Postgres. Trying to fuzz the SQL interpreter in general is not very productive because traditional fuzzers try to execute the entire program repeatedly and it has a fairly high startup and shutdown cost. Also the instrumentation-guided

Hi Mitch, Thank you for the response. 1. You don't need to build the library with `-fsanitize-coverage=...`, using `-fsanitize=fuzzer-no-link,address` should be sufficient. - Acknowledged 2. (although you can actually build object files/shared libraries with -fsanitize=fuzzer, and the libFuzzer main won't be linked, if this makes your build process easier). - with just the *fuzzer

On Wed, Feb 1, 2017 at 9:19 AM, Michael Kruse <llvmdev at meinersbur.de> wrote: > 2017-02-01 18:07 GMT+01:00 Kostya Serebryany <kcc at google.com>: > > Yes, I used to run clang-fuzzer and clang-format-fuzzer on this bot, but > not > > any more. > > The reason is simple -- the bot was always red (well, orange) and the > bugs > > were never fixed. >

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

2017-02-01 17:45 GMT+01:00 Mehdi Amini <mehdi.amini at apple.com>: > >> On Feb 1, 2017, at 8:34 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> The blog entry [1] suggest that one of the buildbots constantly fuzzes >> clang and clang-format. However, the actual bot [2] only tests the >> fuzzer itself

Hi all, The blog entry [1] suggest that one of the buildbots constantly fuzzes clang and clang-format. However, the actual bot [2] only tests the fuzzer itself over a well-known set of bugs in standard software (eg. Heartbleed [3] seems to be among them). Has there actually ever been a buildbot that fuzzes clang/LLVM itself? Another (obvious?) fuzzing candidate would be the LLVM's bitcode

Hi there. I’m trying to use LibFuzzer on OSX and face some issues: I checked out LibFuzzer documentation[1] and managed to proceed until the final step of the first example. Now I see linker errors related to dfsan, dfsan’s documentation[2] states explicitly “DataFlowSanitizer is a work in progress, currently under development for x86_64 Linux.”. Does it mean that LibFuzzer available only on

Afternoon, I had an issue with trying to link a program with the DataFlowSanitizer functionality, this is from the libFuzzer project, and I was seeing: 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

I'd like to discuss the following change: https://reviews.llvm.org/D37526 For the context, there is a comment in compiler-rt/lib/fuzzer/FuzzerExtFunctionsWeak.cpp: // Implementation for Linux. This relies on the linker's support for weak // symbols. We don't use this approach on Apple platforms because it requires // clients of LibFuzzer to pass ``-U _<symbol_name>`` to the

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

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

Hello, Is this reproducible? > Fuzzing is a probabilistic business and one or even two runs don't prove > much. > I've reproduced the behavior on two different machines. Attached is a script to do so. To use the script, - create an empty folder and copy both prune-blocks.sh and ff-http-parser.sh in there - ensure clang and clang++ are in your $PATH - cd /path/to/prune-blocks.sh