similar to: [LLVMdev] [cfe-dev] -fsanitize=address on centos 6.4

GNU ld version 2.20.51.0.2-5.36.el6 20100205 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. From: Kostya Serebryany [mailto:kcc at google.com] Sent: Monday, August 19, 2013 5:36 AM To: Sergey Matveev Cc:

+kcc, llvmdev I think your compiler-rt checkout is out of date, because r188635 is supposed to fix that exact issue. On Mon, Aug 19, 2013 at 9:16 PM, Sharma, Yogesh < Yogesh.Sharma at saabsensis.com> wrote: > Sorry about that. I forgot a d:**** > > ** ** > > ldd (GNU libc) 2.12**** > > Copyright (C) 2010 Free Software Foundation, Inc.**** > > This is free

I did a make update. I thought I was running the newest version of compiler-rt. But now I can't even get the project to build. I get the following error: i386-redhat-linux-gnu-clang++: clang/llvm/include/llvm/ADT/SmallVector.h:544: typename llvm::SmallVectorTemplateBase<T, llvm::isPodLike::value>::iterator llvm::SmallVectorImpl<T>::insert(typename

This looks like the output of "ld --version". What we need is your glibc version, which is given by "ldd --version". On Mon, Aug 19, 2013 at 8:26 PM, Sharma, Yogesh < Yogesh.Sharma at saabsensis.com> wrote: > GNU ld version 2.20.51.0.2-5.36.el6 20100205**** > > Copyright 2009 Free Software Foundation, Inc.**** > > This program is free software; you may

> We have plans to actually compile the symbolizer into the binary and do > in-process symbolization, but it's not there yet. nice! > I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other These two projects don't need to be interdependent and, for the most part, they aren't. In the same way that llvm does not depend on clang, compiler-rt

The sanitizer common and asan that mention 'thread' are failing for me this morning. How are your bots looking? Last good commit here was 512c616cacf70ca029a2bf719a482b902f3687cd. > You could try preprocessing your report with perl or sed to fix paths > to your binaries. It would be great to have an option for that in > asan_symbolize.py. > > As for addr2line, we just

On Thu, May 30, 2013 at 10:05 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The sanitizer common and asan that mention 'thread' are failing for me > this morning. How are your bots looking? Last good commit here was > 512c616cacf70ca029a2bf719a482b902f3687cd. > Hm, our bots seem to be green. Could you refer to guilty svn revision? > > > You could try

As a temporary fix, you can replace this line in sanitizer_linux_libcdep.c: const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1216, 2304); with const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304); The tests should pass after that. I need to figure out which ifdefs to put this under, so I might not be able to land the fix until Monday. On Fri, May 31, 2013 at 8:48 PM, Greg

> const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304); Yes, that change causes all tests to pass. > I need to figure out which ifdefs to put this under, so I might not be able to land the fix until Monday. Okay, no worries, thanks for doing this. I've moved over to release_33 for the short-term. With the one change mentioned earlier (#include <stdint.h>), asan

Those changes shouldn't affect ARM at all, since everything is under #if defined(__i386__) || defined(__x86_64__). What version of glibc are you building with on x86? On Fri, May 31, 2013 at 7:16 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The failures happen on x86 Linux, Ubuntu Lucid. On ARM Android, my > example code segfaults, whereas before it worked. I

> What version of glibc are you building with on x86? 2.11.1 for 64-bit x86 linux $ ldd --version ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.8) 2.11.1 On Fri, May 31, 2013 at 8:24 AM, Sergey Matveev <earthdok at google.com> wrote: > Those changes shouldn't affect ARM at all, since everything is under #if > defined(__i386__) || defined(__x86_64__). > > What version of glibc are

I'm confused - do those test failures happen on x86 Android? On Fri, May 31, 2013 at 10:48 AM, Sergey Matveev <earthdok at google.com>wrote: > r182853 introduced an assumption about the size of thread descriptor in > glibc. On your system it's 48 bytes off, which is why the tests fail. What > version of libc are you using? > > (Repeating - my previous message got

The failures happen on x86 Linux, Ubuntu Lucid. On ARM Android, my example code segfaults, whereas before it worked. I wasn't planning to debug that though since there are unit test failures on x86 Linux. Greg On May 31, 2013, at 2:37 AM, Sergey Matveev <earthdok at google.com> wrote: > I'm confused - do those test failures happen on x86 Android? > > > On Fri, May

I get leaks from a system library: ==16272==ERROR: LeakSanitizer: detected memory leaks Direct leak of 148 byte(s) in 2 object(s) allocated from: #0 0x4a3172 in __interceptor_malloc .../build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3 #1 0x7f575d8df1fe in wcsdup (/lib64/libedit.so.0+0x1c1fe) I don't think I can fix this... ;] -Chandler -------------- next part

r182853 introduced an assumption about the size of thread descriptor in glibc. On your system it's 48 bytes off, which is why the tests fail. What version of libc are you using? (Repeating - my previous message got stuck in the moderation queue because the quoted text was too long.) -------------- next part -------------- An HTML attachment was scrubbed... URL:

I blame this line in lsan/lit_tests/lit.cfg: # Setup attributes common for all compiler-rt projects. compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", "compiler-rt", "lib", "lit.common.cfg") On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <samsonov at google.com>wrote: > > On Fri, May 24,

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

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

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

On Fri, May 30, 2014 at 1:53 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com > wrote: > On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <vonosmas at gmail.com> > wrote: > > Hi, > > > > I consider reducing the usage of blacklist in sanitizer instrumentation > > passes and doing the necessary work in frontend (Clang) instead. > > > > Some