similar to: [LLVMdev] ASAN tests on ARM

I'm getting this link failure when running ninja check on Linux. I'm configuring with shared libraries enabled, so I'm not sure why asan is looking for .a archives. $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TESTS=ON -DCLANG_INCLUDE_DOCS=ON -DBUILD_SHARED_LIBS=ON ../llvm $ ninja check-all FAILED: cd [..]bld/projects/compiler-rt/lib/asan/tests &&

+Alexey On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> wrote: > > I'm getting this link failure when running ninja check on Linux. I'm > configuring with shared libraries enabled, so I'm not sure why asan is > looking for .a archives. > > $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TESTS=ON > -DCLANG_INCLUDE_DOCS=ON

Looking On Thu, Feb 25, 2016 at 9:13 PM, Kostya Serebryany <kcc at google.com> wrote: > +Alexey > > On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> > wrote: > >> >> I'm getting this link failure when running ninja check on Linux. I'm >> configuring with shared libraries enabled, so I'm not sure why asan is >>

Evgeniy, I'm getting this error while building on ARM: clang (LLVM option parsing): Unknown command line argument '-asan-instrument-assembly'. Try: 'clang (LLVM option parsing) -help' clang (LLVM option parsing): Did you mean '-asan-instrument-atomics'? [6/32] Generating ASAN_INST_TEST_OBJECTS.asan_asm_test.cc.arm-inline.o This doesn't happen on x86_64, so

Fixed by LLVM r262063, thanks for reporting this! On Fri, Feb 26, 2016 at 11:35 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Looking > > On Thu, Feb 25, 2016 at 9:13 PM, Kostya Serebryany <kcc at google.com> wrote: > >> +Alexey >> >> On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> >> wrote: >>

I've finished my initial set of patches to make 32-byte shadow granularity work on x86. Here is a summary of the changes from last week: - As discussed, I added a full redzone after every stack variable. - We discussed adding a -fsanitize-address-granularity=N flag, but I found the following existing flag has been sufficient for my purposes: -asan-mapping-scale N. If anyone thinks I

On 7 October 2014 20:55, Evgeniy Stepanov <eugenis at google.com> wrote: > Can you elaborate on this? Does it ever clean those lines? These > numbers are correct on multiple other platforms. I wonder if it's some > codegen peculiarity that leads to this off-by-one mistake? Can you go > down to the individual compile/run invocation and verify that line > numbers match (or

Some updates: First, thanks so much for creating these test suites. Troubleshooting is going very quickly! > There is some flakiness in SanitizerCommon.SpinMutex test. Yes, I'm seeing that too. SpinMutexTry as well. Should these be disabled? > ARM JellyBean works over here. I found a configuration that works well on JB 4.1.2 and 4.2.2. The trick is to build the ASan *runtime*

For the same reason we use shared runtime on OSX. We intercept libc calls by declaring a function with the same name in the sanitizer runtime library. Glibc loader puts main executable early in the symbol lookup order, which lets us interpose symbols from shared libraries with symbols from statically linked sanitizer runtime. Android (and AFAIK most other platforms) does not allow that, which is

On 8 October 2014 12:38, Evgeniy Stepanov <eugenis at google.com> wrote: > When running the final binary. Same thing... :( Should I bisect where that got broken? Do you have any way of testing that locally? This is just a basic CMake build on ARM, nothing special. "ninja check-asan". cheers, --renato

+eugenis@ On Sat, Sep 21, 2013 at 4:58 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Why does compiler-rt ship a shared object for ASan on Android instead > of a static library? Would statically linking ASan on Android at > least be safe for standalone executables? > > And if I'm wanting to use ASan in C++ code that is invoked from an > APK, can I statically

> Static runtime will only intercept calls from the main executable, but > not from any libraries. This may work for simple standalone programs, > but you may run into puzzling failures. What type of failures do you mean? Does the symbol mismatch break assumptions in the ASan runtime? It's easy to imagine, for example, ASan missing use-after-free bugs because the call to free() is

On Fri, Oct 18, 2013 at 3:27 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Some updates: > > First, thanks so much for creating these test suites. Troubleshooting > is going very quickly! > > > > There is some flakiness in SanitizerCommon.SpinMutex test. > > Yes, I'm seeing that too. SpinMutexTry as well. Should these be disabled? > There is an

From: http://address-sanitizer.googlecode.com/svn-history/r1624/wiki/Android.wiki > AddressSanitizer is fully supported in AOSP starting with JellyBean release. To run > applications built with ASan you'll need an -eng build of Android. > > To build any part of Android system with ASan, add > LOCAL_ADDRESS_SANITIZER:=true to the appropriate Android.mk. I don't see that

Hi Evgeniy, Now that I can run check-asan without the AArch64 tests, there are a number of ARM tests that fail with the wrong line number on the CHECK line... use-after-delete.cc:20:18: error: expected string not found in input // CHECK-Linux: {{ #1 0x.* in main .*use-after-delete.cc:}}[[@LINE-10]] <stdin>:9:33: note: with expression "@LINE-10" equal to "10" #0

On 8 October 2014 11:18, Evgeniy Stepanov <eugenis at google.com> wrote: > Something you could try: ASAN_OPTIONS=fast_unwind_on_malloc=0 should > switch to cfi unwinder and fix the stack trace, but that's not a > solution to the problem. Is this when compiling Clang? The file? or running the final binary? --renato

You are citing the "Android platform workflow" section, which is about sanitizing components of the Android system itself. For NDK apps, see "Android NDK workflow" in the same document. You need -eng build because preloading libraries into dalvik vm is not allowed in user builds. JellyBean includes several bugfixes in the dynamic loader that asan needs. Was there any useful

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

I'm following these instructions with the latest code from llvm.org: https://code.google.com/p/address-sanitizer/source/browse/trunk/build/scripts/slave/buildbot_cmake.sh Of SanitizerTest, AsanTest and AsanNoinstTest, I cannot get any of the 3 to pass all its tests. I've tried using an Android device running JellyBean as well as the latest Android Emulator (20130917, api level 18).

On 3 October 2014 14:42, Evgeniy Stepanov <eugenis at google.com> wrote: > this happens when x86 target is not compiled in. We really should (and > will) do something about it. > > Btw, you've asked the same question a month ago :) Sorry it has been > an issue for such a long time. No worries, I also haven't done much. But I need to get the RT bot green soon enough.