similar to: [LLVMdev] ASan and UBSan Test Failures

Some more information … On Jan 4, 2013, at 6:56 PM, Meador Inge wrote: > I am building LLVM on OS X 10.7.5 with cmake. Under this configuration some ASan and UBSan tests > are failing: > > $ make check-ubsan > > … > > ******************** > Testing Time: 2.36s > ******************** > Failing Tests (11): > UndefinedBehaviorSanitizer ::

I also encounter this issue and solved it locally by implementing this 2 functions. - The linux version of StartSymbolizerSubprocess uses only POSIX function and can be reused as is on OS X (maybe we should move it in a new sanitizer_symbolizer_posix.cc file) - I have a simple implementation of GetListOfModules (see the attached file) but it required 10.6 at least. That said, implementing this

On Sun, Jan 6, 2013 at 4:03 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > I also encounter this issue and solved it locally by implementing this 2 > functions. > > - The linux version of StartSymbolizerSubprocess uses only POSIX function > and can be reused as is on OS X (maybe we should move it in a new > sanitizer_symbolizer_posix.cc file) > - I have a

Hi Evgeniy, So, to XFAIL some UBSAN failues, I found an issue: UndefinedBehaviorSanitizer-AddressSanitizer :: TestCases/TypeCheck/vptr.cpp UndefinedBehaviorSanitizer-Standalone :: TestCases/Misc/missing_return.cpp These two tests fail on that configuration, but pass when reversed. So, if I XFAIL: armv7l..., I get the following error: UndefinedBehaviorSanitizer-AddressSanitizer ::

I've been working on adding UBSan support to CMake (so that errors found by it can be uploaded to CDash for viewing). One problem is that the message is very generic. The patch here addes 'UndefinedBehaviorSanitizer' to the message so that they may be detected more easily. If something else is wanted (such as the '===' lines from ASan or TSan to cope with things like printing

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

Kostya, Christophe, I'm running the full tests on AARch64 and the only RT test that fails is: UndefinedBehaviorSanitizer-Standalone :: TestCases/Float/cast-overflow.cpp The problem seems to be a trap in __sanitizer::internal_memchr() while trying to handle __ubsan::__ubsan_handle_float_cast_overflow(). I haven't looked at it in detail, has anyone seen this? Is UBSan meant to run on

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

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

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

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

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

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

> 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 -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

Hi all, UndefinedBehaviorSanitizer currently does not check for undefined behaviors which result from improper usage of standard library functions. One notorious instance of such errors is invalid usage of qsort or bsearch routines (or std::sort and friends in case of C++): * using comparison function that violates ordering axioms (reflexivity, symmetry, transitivity) * returning unstable

Dear all, bigKRLS, which has been on CRAN for a couple of years, had to be pulled recently due to what seems to be a sanitizer issue stemming from its use of bigmemory. bigKRLS works fine (we?ve used it ourselves on many different platforms and have had over 15,000 downloads without an end user reporting difficulties because of this issue). Unfortunately, we have been unable to reproduce the

Folks, As of this run: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/746 There are three classes of failures that need fixing before we get the bot green: 1. AddressSanitizer.BuiltinLongJmpTest Unit Test Two configurations fail: * Asan-arm-inline-Test * Asan-arm-with-calls-Test I wonder what's the best way to run it individually and reduce the error. I'm not

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