similar to: -fsanitize=memory failing on 3.9.0

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

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

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

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

Hm, I tried to reproduce this as well, but unsuccessfully. From the crash report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17, which is just after the prologue and just after calling cur_thread(). So I’d say it happens when we’re dereferencing the pointer returned by cur_thread(). On OS X, we’re

When I build compiler-rt with clang 3.2, all lsan tests pass. The only failing tests I see are in ubsan: Failing Tests (6): UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp UndefinedBehaviorSanitizer :: Integer/div-zero.cpp UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp UndefinedBehaviorSanitizer ::

Ah ha! I found crash reports: green-dragon-03:DiagnosticReports buildslave$ cat mmap_stress.cc.tmp_2016-01-19-231335_green-dragon-03.crash Process: mmap_stress.cc.tmp [95010] Path: /Users/USER/*/mmap_stress.cc.tmp Identifier: mmap_stress.cc.tmp Version: 0 Code Type: X86-64 (Native) Parent Process: bash [95004] User ID:

With all of Xen''s symbols sitting within a 2Gb range on x86-64, they can be referred to by the kallsyms-like offset table using 4- instead of 8-byte slots. The marker table can use 4-byte slots in all cases, just like the table entry counts can (though that''s only a minor improvement). If ia64''s PERCPU_ADDR got moved down to (KERNEL_START + 2Gb - PERCPU_PAGE_SIZE), it

On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> > wrote: > > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > > failing tests I see are in ubsan: > > > > Failing Tests (6): > > UndefinedBehaviorSanitizer ::

UBsan tests work for me when I run "check-ubsan" in both build trees (the one with gcc 4.6.3 as a host compiler, and the one with fresh Clang). It's pretty convenient for us to use fresh Clang to configure LLVM and compiler-rt. One major reason is that autoconf/make build system always builds compiler-rt with just-built Clang. There are other benefits, like keeping sanitizers code

On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> wrote: > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > failing tests I see are in ubsan: > > Failing Tests (6): > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp > UndefinedBehaviorSanitizer ::

> Android runtime is special, we build it in a separate build tree configured with > -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake This worked great, thanks! Would you mind tweaking Android.cmake so that I can override the location of the C compiler? The current version forces me to use the just-built-clang and that the new build directory be in a sibling directory.

On Wed, May 29, 2013 at 5:40 PM, Greg Fitzgerald <garious at gmail.com> wrote: > For me, UBsan fails with clang 3.2 and passes with clang 3.3. > Cool, can you use clang 3.3 then? :) I think that the reason selected UBSan tests fail under clang 3.2 is a bug in Clang, which was fixed (Richard may correct me if I'm wrong). I don't really want to mark these tests as "failing

On Thu, May 30, 2013 at 3:40 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > Cool, can you use clang 3.3 then? :) > > I can, but digging deeper I see that the compiler-rt sanitizer tests > depend on just-built-clang for its object instrumentation. The next time > the instrumentation changes, I'd expect those tests to break. If the lit > tests that require

For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote: > UBsan tests work

Hi there, I'm trying to use the memory sanitizer of LLVM 3.3. It's crashing during MSan initialization (__msan::InitShadow). Here's the strace output. mmap(0x400000000000, 35184372088831, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x400000000000 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x55edf4b36720} --- +++ killed by SIGSEGV (core

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

Hi Sanitizer Runtime Developers, We recently ran into a problem building clang because some of the definitions in sanitizer_common conflicted with system definitions and later another system header was trying to use the system definition: .../usr/include/libkern/OSAtomicDeprecated.h:756:17: error: reference to 'memory_order_relaxed' is ambiguous __theAmount, memory_order_relaxed) +

Hi, I am using clang++3.9 to build a simple program with both CFI and safe-stack. I am getting linker errors when combining -fsanitize=safe-stack, -fsanitize=cfi, and -fno-sanitize-trap=all. Combining safe-stack and CFI without -fno-sanitize-trap=all works as expected. It looks like clang is attempting to link in two compiler-rt libraries, one for ubsan and one for safestack, and this causes