similar to: libfuzzer questions

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

I ran "ninja check-asan" and no errors. But "ninja check-msan" had 117 errors. I took the first FAILED test, which was for eventfd.cc, and executed the command line creating an eventfd executable in a temporary directory and then executed that file using gdb. Finally, used bt to dump the stack. I've emailed llvm-admin at lists.llvm.org to setup an account since

I've "successfully" built 3.9.0 release but when I run "ninja check-all" I got 208 Unexpected failures: Expected Passes : 33997 Expected Failures : 198 Unsupported Tests : 685 Unexpected Failures: 208 Below is the log I captured running "time ninja check-all | tee ninja-check-all.txt" https://drive.google.com/open?id=0B-KTY7zi7eZHU2hGYTRtd01QZjA

I've compiled REALEASE_390/final but all "ninja check-msan" tests are failing (http://lists.llvm.org/pipermail/llvm-dev/2016-September/104609.html) I'm waiting for an account to be created to file a bug, but in the mean time I thought I'd take a look at it myself. My system is an Arch Linux system that is up to date as of this morning: $ uname -a Linux wink-desktop

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

Hello, I'm quite new to LLVM, but I'm interested in memory sanitizer. The petty thing is, that 32bit addressing on Linux is not supported. Thus I tried to take the latest version of the software and to modify it, using Ubuntu 16.04 as operating system. Given the example example.c: #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { int *a = (int

On 31 Jul 2017, at 19:26, Hans Wennborg <hans at chromium.org> wrote: > > On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimitry at andric.com> wrote: >> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote: >>> >>> 5.0.0-rc1 has just been tagged. >>> >>> Please build, test and upload binaries

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no

On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimitry at andric.com> wrote: > On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote: >> >> 5.0.0-rc1 has just been tagged. >> >> Please build, test and upload binaries to the sftp. Let me know if >> there are any issues. > > Built and tested rc1. Test failures on

Hi all, I've included an RFC for a heap profiler design I've been working on in conjunction with David Li. Please send any questions or feedback. For sanitizer folks, one area of feedback is on refactoring some of the *ASAN shadow setup code (see the Shadow Memory section). Thanks, Teresa RFC: Sanitizer-based Heap Profiler Summary This document provides an overview of an LLVM

Hello xapian users, The server I'm compiling on is a little odd. SunOS on a sun4 architecture. Fails when linking, gives the following, memcpy 0x10 /usr/local/gcc-3.3.2/lib/./libstdc++.a(ctype.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status *** Error code 1 make: Fatal error:

On Sat, Jul 4, 2020 at 11:28 PM Wenlei He <wenlei at fb.com> wrote: > This sounds very useful. We’ve improved and used memoro > <https://www.youtube.com/watch?v=fm47XsATelI> for memory profiling and > analysis, and we are also looking for ways to leverage memory profile for > PGO/FDO. I think having a common profiling infrastructure for analysis > tooling as well as

On Wed, Jul 8, 2020 at 6:30 PM Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jun 24, 2020 at 4:58 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> Hi all, >> >> I've included an RFC for a heap profiler design I've been working on in >> conjunction with David Li. Please send any questions or feedback. For >>

On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote: > On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: > > > > 8.0.0-rc1 was just tagged (from the branch at r351980). > > > > It took a little longer than planned, but it's looking good. > > > > Please run the test

Hi, Teresa, This looks really useful. It seems like this general infrastructure could be useful for diagnosing places where we have a lot of false sharing too. This could be between cores, sockets, or devices. Looking forward, especially with HMM and support under Linux for transparent unified memory between CPUs and accelerators, I anticipate we'll end up looking for places where some

Hi, On Linux I observed [root at localhost poolalloc]# find . -name *.a ./Release+Asserts/lib/LLVMDataStructure.a ./Release+Asserts/lib/poolalloc.a ./Release+Asserts/lib/AssistDS.a ./Release+Asserts/lib/libpoolalloc_fl_rt.a ./Release+Asserts/lib/libpoolalloc_rt.a ./Release+Asserts/lib/libpa_pre_rt.a ./Release+Asserts/lib/libcount.a On cygwin I observed kpawar at KPAWAR-LT

Hi John, That worked for me. I am using llvm 3.2 only and following http://safecode.cs.illinois.edu/docs/Install.html So for I am able to make inside llvm/projects/poolalloc by doing such cosmetic changes. Now, when I tried to make inside llvm/projects/safecode, I see another error. kpawar at KPAWAR-LT ~/SAFECode/LLVM_SRC/llvm/projects/safecode $ /usr/bin/clang -cc1 -triple

I have some code generated with llvm-g++ and llvm-link that includes a tail call that is confusing me for two reasons: 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position) 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on. Below I