The mips64el compiler-rt build has recently been enabled. XFAIL the failing
tests to make the buildbot green again.
The two asan tests require the integrated assembler. This will be fixed soon
for Debian mips64el but not for any other mips64el targets since doing so
requires triple-related issues to be fixed..
The msan tests are largely failing because caused by a kernel update (a patch
has already been posted for this).
I'm not sure why the dfsan test fails yet.
llvm-svn: 278504
This patch adds the __sanitizer_start_switch_fiber and
__sanitizer_finish_switch_fiber methods inspired from what can be found here
2ea64dd249 .
These methods are needed when the compiled software needs to implement
coroutines, fibers or the like. Without a way to annotate them, when the program
jumps to a stack that is not the thread stack, __asan_handle_no_return shows a
warning about that, and the fake stack mechanism may free fake frames that are
still in use.
Author: blastrock (Philippe Daouadi)
Reviewed in http://reviews.llvm.org/D20913
llvm-svn: 273260
available along side the leak checking, so use the REQUIRES for that.
Also, use %run as other tests do when launching the built binary.
This fixes check-asan for me on Linux and looks like it should fix the
linux sanitizer bots as well.
llvm-svn: 271785
In recovery mode, when ASan detects stack overflow (say, when infinite recursion detected),
it tries to continue program execution and hangs on repetitive error reports. There isn't any
sense to do it, we can just bail out on stack overflow error, because the program would crash soon anyway.
Differential Revision: http://reviews.llvm.org/D19958
llvm-svn: 268713
On s390*-linux, sigcontext just doesn't contain any information that could
be used to recover the type of access, so there's no way to fix this, short
of emulating the faulting instruction.
Differential Revision: http://reviews.llvm.org/D19655
llvm-svn: 267960
This reverts commit r267477.
It broke our bots that enables the AArch64 backends, it seems that
this code is using a Darwin *X86 specific* field.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267526
With -fsized-deallocation, new[] vs delete mismatch is reported as
new-delete-type-mismatch. This is technically true, but
alloc-dealloc-mismatch describes it better.
llvm-svn: 266246
Summary:
Adds another global to asan's odr_c_test to help force the target global to
not lie at the start of bss with the gold linker where it is always
aligned.
Patch by Derek Bruening!
llvm-svn: 262678
This testcase failed on sanitizer-x86_64-linux buildbot in large parallel build due to race on
port 1234 between AddressSanitizer-i386-linux and AddressSanitizer-x86_64-linux instances of recvfrom.cc.
This patch tries to resolve the issue by relying on kernel to choose available port instead of hardcoding
its number in testcase.
Differential Revision: http://reviews.llvm.org/D17639
llvm-svn: 262204
Pass res instead of len as third parameter to COMMON_INTERCEPTOR_WRITE_RANGE,
because otherwise we can write to unrelated memory (in MSan) or get wrong report (in ASan).
Differential Revision: http://reviews.llvm.org/D17608
llvm-svn: 261898
This patch moves recv and recvfrom interceptors from MSan and TSan to
sanitizer_common to enable them in ASan.
Differential Revision: http://reviews.llvm.org/D17479
llvm-svn: 261841
Test cases definitely should not care about the complete set of architectures
supported by compiler-rt - they should only care about current
architecture that the test suite was configured for.
Introduce new lit feature to reflect this, and convert tests to use it.
llvm-svn: 261603
This is a compiler-rt part of this http://reviews.llvm.org/D15642 patch. Here,
we add a new approach for ODR violation detection.
Instead of using __asan_region_is_poisoned(g->beg, g->size_with_redzone) on
global address (that would return false now due to using private alias), we can
use new globally visible indicator symbol to perform the check.
Differential Revision: http://reviews.llvm.org/D15644
llvm-svn: 260076
Calloc interceptor initially allocates memory from temp buffer (to serve dlsyms called during asan_init). There is a chance that some non-instrumented library (or executable) has allocated memory with calloc before asan_init and got pointer from the same temporary buffer which later caused problems with free.
Inspired by https://github.com/google/sanitizers/issues/626
Differential Revision: http://reviews.llvm.org/D14979
llvm-svn: 254395