search for: asantest

..."errors", mostly from asan_mac_test.mm. After fixing up these "errors" (int vs. size_t comparisons and malloc being assigned to volatile pointers), I got 372 duplicate symbol errors from this: Ld /Volumes/Shared/NewShared/llvm/3.2/xcode/projects/compiler-rt/lib/asan/tests/Debug/AsanTest normal x86_64 cd /Volumes/Shared/NewShared/llvm/3.2/source setenv MACOSX_DEPLOYMENT_TARGET 10.8 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve...

...s", mostly from asan_mac_test.mm. After fixing up these "errors" (int vs. size_t comparisons and malloc being assigned to volatile pointers), I got 372 duplicate symbol errors from this: > > Ld /Volumes/Shared/NewShared/llvm/3.2/xcode/projects/compiler-rt/lib/asan/tests/Debug/AsanTest normal x86_64 > cd /Volumes/Shared/NewShared/llvm/3.2/source > setenv MACOSX_DEPLOYMENT_TARGET 10.8 > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOS...

...from asan_mac_test.mm. After fixing up these "errors" (int vs. size_t > comparisons and malloc being assigned to volatile pointers), I got 372 > duplicate symbol errors from this: > > Ld > /Volumes/Shared/NewShared/llvm/3.2/xcode/projects/compiler-rt/lib/asan/tests/Debug/AsanTest > normal x86_64 > cd /Volumes/Shared/NewShared/llvm/3.2/source > setenv MACOSX_DEPLOYMENT_TARGET 10.8 > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ > -arch x86_64 -isysroot > /Applications/Xcode.app/Contents/Develop...

...asan_mac_test.mm<http://asan_mac_test.mm/>. After fixing up these "errors" (int vs. size_t comparisons and malloc being assigned to volatile pointers), I got 372 duplicate symbol errors from this: Ld /Volumes/Shared/NewShared/llvm/3.2/xcode/projects/compiler-rt/lib/asan/tests/Debug/AsanTest normal x86_64 cd /Volumes/Shared/NewShared/llvm/3.2/source setenv MACOSX_DEPLOYMENT_TARGET 10.8 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve...

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 > symbol vtable for llvm::convertible_fwd_ostream means the weak symbol > cannot be overridden at runtime. This was likely caused by different > translation units being compiled...

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 translation units being compiled with different visibilit...

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). What run-time environments are known to work? Thanks, Greg

...its install directory, and the test suite from the CMake build uses the local copy of the ASan runtime for testing. To reproduce the error I'm seeing, run the Android CMake build in the Release+Asserts directory of the Make build. Install the ASan runtime from the Make build and then run the AsanTests test suite. Thanks, Greg On Wed, Oct 16, 2013 at 11:55 PM, Evgeniy Stepanov <eugenis at google.com> wrote: > 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 gma...

...t 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 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). What run-time environments are known to work? > > Thanks, > Greg > ____________...

On Fri, Nov 02, 2012 at 06:45:07PM +0400, Alexey Samsonov wrote: > Hi, Jack! > > > I'll take a look at this. However, tests below fail for a different reason > (they don't use Debug/AsanTest at all). > How do you configure a CMake build tree? Can you somehow get (or run > manually) the script which is used > for running log-path_test.cc and other failing test cases? > > I have in build/projects/compiler-rt/lib/asan/lit_tests/Output/log-path_test.cc.tmp.log.393 ======...

...and the test suite from the CMake build uses the local copy > of the ASan runtime for testing. > > To reproduce the error I'm seeing, run the Android CMake build in the > Release+Asserts directory of the Make build. Install the ASan runtime > from the Make build and then run the AsanTests test suite. > Do you mean it's a compile-time issue with the path in Android.cmake? > > Thanks, > Greg > > On Wed, Oct 16, 2013 at 11:55 PM, Evgeniy Stepanov <eugenis at google.com> > wrote: > > ARM JellyBean works over here. There is some flakiness in >...

.... [100%] Running all regression tests lit.py: lit.common.cfg:19: note: using clang: '/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/bin/clang' lit.py: lit.cfg:171: note: using clang: '/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/bin/./clang' FAIL: AddressSanitizer-Unit :: Release/AsanTest/AddressSanitizerMac.GCDSourceCancel (162 of 12631) ******************** TEST 'AddressSanitizer-Unit :: Release/AsanTest/AddressSanitizerMac.GCDSourceCancel' FAILED ******************** Note: Google Test filter = AddressSanitizerMac.GCDSourceCancel [==========] Running 1 test from 1 test cas...

Context: I'm trying to implement support for ASan's unittest suite in CMake. This is ... quite challenging. I think I can get it to work with one significant caveat: it will require manual dependency management. None of the automatic header tracking. I think this is fine in some cases, and not so fine in other cases. Let me explain. It feels like these tests are really comprised of two