similar to: [LLVMdev] UBSAN - Test failures

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 :: Float/cast-overflow.cpp UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp UndefinedBehaviorSanitizer :: Integer/div-zero.cpp

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

Hi Adhemerval, Some UBSan tests are timing out randomly. http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full ex: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/902 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/894 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/906

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

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

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

On 01/13/2016 03:10 AM, Kostya Serebryany wrote: > FTR, here is one way to implement this in the library: > https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h > Search for "check sort predicate for strict weak ordering" Nice, although this wouldn't catch violations of transitivity (which is probably the most important type of bug).

(+correct cfe-dev list) On Tue, Jan 12, 2016 at 2:57 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Hi Yuri, > > On Mon, Jan 11, 2016 at 9:53 AM, Yury Gribov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> UndefinedBehaviorSanitizer currently does not check for undefined >> behaviors which result from improper usage

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

On 01/13/2016 09:57 AM, Kostya Serebryany wrote: > On Tue, Jan 12, 2016 at 10:28 PM, Yury Gribov <y.gribov at samsung.com> wrote: > >> On 01/13/2016 03:10 AM, Kostya Serebryany wrote: >> >>> FTR, here is one way to implement this in the library: >>> >>> https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h

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

Inviting Paul to the party (he wrote the libstdc++ sort checker <https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h> ). On Tue, Jan 12, 2016 at 11:09 PM, Yury Gribov <y.gribov at samsung.com> wrote: > On 01/13/2016 10:08 AM, Yury Gribov wrote: > >> On 01/13/2016 09:57 AM, Kostya Serebryany wrote: >> >>> On Tue, Jan 12,

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

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

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

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

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

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

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