similar to: [LLVMdev] ASan testing on Android

ARM JellyBean works over here. There is some flakiness in SanitizerCommon.SpinMutex test. On Wed, Oct 16, 2013 at 11:36 PM, Greg Fitzgerald <garious at gmail.com> wrote: > 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

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*

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

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

Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM 3.2 (with clang, extras, and compiler-rt) building - but not testing - on Xcode. I used CMake 2.8.10 GUI to create the Xcode project file. Below are my notes. First, I believe CMake ends up setting things up so that Xcode has 1 warning after scanning the project having to do with hires images or some such… it takes

Hi Richard! On Thu, Dec 20, 2012 at 12:48 AM, Nick Kledzik <kledzik at apple.com> wrote: > Those look like the linker is being passed the same .o file built twice, > ex: > ../Objects-normal/x86_64/asan_globals_test.o > ../lib/asan/tests/asan_globals_test.cc.asan.o > > So, the symbols are colliding. Something is set up wrong in the xcode > project. > > -Nick

This morning I'm seeing 4 new sanitizer failures in SanitizerCommon-Unit (compared to a couple of days ago, when I didn't see these) - perhaps related to recent library refactoring? SanitizerCommon-Unit :: Sanitizer-i386-Test/DeadlockDetector.RemoveEdgesTest SanitizerCommon-Unit :: Sanitizer-i386-Test/SanitizerCommon.ThreadRegistryTest SanitizerCommon-Unit ::

Those look like the linker is being passed the same .o file built twice, ex: ../Objects-normal/x86_64/asan_globals_test.o ../lib/asan/tests/asan_globals_test.cc.asan.o So, the symbols are colliding. Something is set up wrong in the xcode project. -Nick On Dec 19, 2012, at 9:48 AM, Relph, Richard wrote: > Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM

Hi, I'm seeming new regressions form 4.0.0 for mips big endian: DataFlowSanitizer-mips64 :: custom.cc DataFlowSanitizer-mips64 :: propagate.c SanitizerCommon-asan-mips-Linux :: sanitizer_coverage_trace_pc_guard-dso.cc SanitizerCommon-asan-mips-Linux :: sanitizer_coverage_trace_pc_guard.cc SanitizerCommon-asan-mips64-Linux :: Linux/getpwnam_r_invalid_user.cc

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

Hi all, I experienced some test failures under Linux, probably caused by r232936: In the test SanitizerCommon-Unit :: Sanitizer-i386-Test/MemoryMappingLayout.CodeRange the temporary test file was opened write-only, but was read from, what subsequently failed: Note: Google Test filter = MemoryMappingLayout.CodeRange [==========] Running 1 test from 1 test case. [----------] Global test

I have simple standalone ASan examples working on Android, and now I'd like to try using ASan with the Android build system. I'm building the release_33 branch of llvm+clang+compiler-rt with CMake. To test, I'm looking at libjpg, because with just a small change its Android.mk it compiles in a few seconds and without needing any additional dependencies. When I run 'djpeg' on

Different, but still failing (this time with Xcode 4.4…) /Users/rrelph/llvm/tot/xcode/bin/Debug/clang sanitizer_allocator_test.cc.i386.o sanitizer_common_test.cc.i386.o sanitizer_flags_test.cc.i386.o sanitizer_libc_test.cc.i386.o sanitizer_list_test.cc.i386.o sanitizer_printf_test.cc.i386.o sanitizer_stackdepot_test.cc.i386.o sanitizer_test_main.cc.i386.o gtest-all.cc.i386.o

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

Nick, Have you noticed that llvm/clang svn produces the following linker warnings on 'make check-all'? Linking CXX executable Debug/AsanTest ld: warning: direct access in llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak symbol vtable for llvm::convertible_fwd_ostream means the weak symbol cannot be overridden at runtime. This was likely caused by different

Hi, Jack! On Fri, Nov 2, 2012 at 6:18 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > Nick, > Have you noticed that llvm/clang svn produces the following linker > warnings on > 'make check-all'? > > Linking CXX executable Debug/AsanTest > ld: warning: direct access in > llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak >

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

Hello everyone, 9.0.0-rc5 was just tagged from the release_90 branch at r371837. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc5. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc5 Binaries will be added as they become available. There is only a single change from rc4 to rc5. Once more, the hope is that this will be the last release candidate and that we can

Hi, I've just tagged LLVM 9.0.1-rc3. Testers can begin testing and uploading binaries. This will be the last release candidate unless there is a major problem. I'm planning to tag the final release on Dec 19. -Tom