Incremented the pc for each architecture in accordance with StackTrace:GetPreviousInstructionPC
Reviewers: samsonov, dvyukov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D17802
llvm-svn: 262483
This code is actually never executed because all RUN lines trigger an
earlier heap-use-after-free, but there is still a compiler warning.
llvm-svn: 262276
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
Summary:
iOS on ARM64 doesn't unique RTTI.
Ref: clang's iOS64CXXABI::shouldRTTIBeUnique()
Due to this, pointer-equality will not necessarily work in this
architecture, across dylib boundaries.
dynamic_cast<>() will (as expected) still work, since Apple ships with
one prepared for this, but we can't rely on the type names being
pointer-equal.
I've limited the expensive strcmp check to the specific architecture
which needs it.
Example which triggers this bug:
lib.h:
struct X {
virtual ~X() {}
};
X *libCall();
lib.mm:
X *libCall() {
return new X;
}
prog.mm:
int main() {
X *px = libCall();
delete px;
}
Expected output: Nothing
Actual output:
<unknown>: runtime error: member call on address 0x00017001ef50 which does not point to an object of type 'X'
0x00017001ef50: note: object is of type 'X'
00 00 00 00 60 00 0f 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for ‘X’
Reviewers: kubabrecka, samsonov, eugenis, rsmith
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D11502
llvm-svn: 262147
This test expects pthread_mutex_init in the frame #0 of thread T1 but we
get memset at frame #0 because memset that is called from pthread_init_mutex
is being intercepted by TSan
llvm-svn: 261986
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
Summary: As per the test the 4th element of both arrays are not initialized and hence will contain garbage values. Memcmp returns the difference between the garbage values of the 4th element which will be different on every run of the test. And since the return value of memcmp is returned from main, we are getting random exit code every time.
Reviewers: kcc, eugenis
Subscribers: mohit.bhakkad, jaydeep, llvm-commits
Differential: http://reviews.llvm.org/D17534
llvm-svn: 261739
The first issue is that we longjmp from ScopedInterceptor scope
when called from an ignored lib. This leaves thr->in_ignored_lib set.
This, in turn, disables handling of sigaction. This, in turn,
corrupts tsan state since signals delivered asynchronously.
Another issue is that we can ignore synchronization in asignal
handler, if the signal is delivered into an IgnoreSync region.
Since signals are generally asynchronous, they should ignore
memory access/synchronization/interceptor ignores.
This could lead to false positives in signal handlers.
llvm-svn: 261658
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
I ran the test suite yesterday and when I came back this morning the
queue_user_work_item.cc test was hung. This could be why the
sanitizer-windows buildbot keeps randomly timing out. I updated all the
usages of WaitForSingleObject involving threading events. I'm assuming
the API can reliably wait for subprocesses, which is what the majority
of call sites use it for.
While I'm at it, we can simplify some EH tests now that clang can
compile C++ EH.
llvm-svn: 261338
Compiler-rt only relies on LLVM for lit support. Pushing this dependency down into the test and unitest layers will allow builtin libraries to be built without LLVM.
llvm-svn: 261105
1. Add two explicit -stdlib=libstdc++ in conjunction with -static-libstdc++
2. Pass -nostdinc++ when adding include paths for libc++ built for tsan. This
prevents clang finding the headers twice which would confuse #include_next
Differential Revision: http://reviews.llvm.org/D17189
llvm-svn: 260883
There's no obvious reason it should fail in this way but it's the only change
on the blamelist. I suspect stale lit*.cfg's from previous builds.
llvm-svn: 260672
The lit test-suite containing the unit tests needs to be explicitly specified
as an argument to lit.py since it is no longer discovered when the other tests
are run (because they are one directory deeper).
dfsan, lsan, and sanitizer_common don't show the same problem.
llvm-svn: 260669
Summary:
In some cases stack pointer register (SP) doesn't point into the thread
stack: e.g. if one is using swapcontext(). In this case LSan
conservatively tries to scan the whole thread stack for pointers.
However, thread stack (at least in glibc implementation) may also
include guard pages, causing LSan to crash when it's reading from them.
One of the solutions is to use a pthread_attr_getguardsize() to adjust
the calculated stack boundaries. However, here we're just using
IsAccessibleMemoryRange to skip guard pages and make the code (slightly)
less platform-specific.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17116
llvm-svn: 260554
This test isn't posix specific, but it doesn't pass on Windows and is
XFAILed. I suspect that this test, which is expected to fail, is causing
the hangs I'm seeing on our WinASan builder. Moving it to Posix seems
to be the cleanest way to avoid running it on Windows.
llvm-svn: 260480
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when lsan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16859
llvm-svn: 260232
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16856
llvm-svn: 260231
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, srhines, llvm-commits
Differential Revision: http://reviews.llvm.org/D16855
llvm-svn: 260230
Summary:
This fixes duplicate test names in the test results, so:
PASS: SanitizerCommon-asan :: fopen_nullptr.c (304 of 431)
PASS: SanitizerCommon-asan :: fopen_nullptr.c (305 of 431)
is now:
PASS: SanitizerCommon-asan-i386-Linux :: fopen_nullptr.c (282 of 431)
PASS: SanitizerCommon-asan-x86_64-Linux :: fopen_nullptr.c (316 of 431)
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16850
llvm-svn: 260227
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
The "sanitizer-windows" buildbot has been failing for two days because of this:
FAILED: cl.exe asan_report.cc
asan_scariness_score.h(60) : error C2536:
'__asan::ScarinessScore::__asan::ScarinessScore::descr' :
cannot specify explicit initializer for arrays
asan_scariness_score.h(60) : see declaration of '__asan::ScarinessScore::descr'
llvm-svn: 260059
Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the vtable pointer against the set of all known vtable addresses and
lets the runtime handler know if it is safe to inspect the vtable.
http://reviews.llvm.org/D16824
llvm-svn: 259717
Summary:
This is a workaround to a problem in the 3.8 release that affects MIPS and
possibly other targets where the default is not supported but a sibling is
supported.
When TSAN_SUPPORTED_ARCH is not empty, cmake currently attempts to build a
tsan'd libcxx as well as test tsan for the default target regardless of whether
the default target is supported or not. This causes problems on MIPS32 since
tsan is supported for MIPS64 but not MIPS32.
This patch causes cmake to only build the libcxx and run the lit test-suite for
archictures in ${TSAN_SUPPORTED_ARCH}
This re-commit fixes an issue where 'check-tsan' continued to look for the
tsan'd libc++ in the directory it used to be built in.
Reviewers: hans, samsonov
Subscribers: tberghammer, llvm-commits, danalbert, srhines, dvyukov
Differential Revision: http://reviews.llvm.org/D16685
llvm-svn: 259542
check-tsan does not pick up the correct libc++.so. It succeeded on my machine
by picking up the libc++.so that was built before making this change.
llvm-svn: 259519
Summary:
This is a workaround to a problem in the 3.8 release that affects MIPS and
possibly other targets where the default is not supported but a sibling is
supported.
When TSAN_SUPPORTED_ARCH is not empty, cmake currently attempts to build a
tsan'd libcxx as well as test tsan for the default target regardless of whether
the default target is supported or not. This causes problems on MIPS32 since
tsan is supported for MIPS64 but not MIPS32.
This patch causes cmake to only build the libcxx and run the lit test-suite for
archictures in ${TSAN_SUPPORTED_ARCH}
Reviewers: hans, samsonov
Subscribers: tberghammer, llvm-commits, danalbert, srhines, dvyukov
Differential Revision: http://reviews.llvm.org/D16685
llvm-svn: 259512
We already disabled various tests relying on C++ ABI knowledge, but we
still tried to build in this configuration on Windows which was a
mistake.
Fixes PR26415.
llvm-svn: 259388
This patch adds support for expanding "%h" out to the machine hostname
in the LLVM_PROFILE_FILE environment variable.
Patch by Daniel Waters!
Differential Revision: http://reviews.llvm.org/D16371
llvm-svn: 259272
test/cfi/cross-dso/dlopen.cpp:67:45: warning: GCC does not allow 'aligned' attribute in this position on a function definition [-Wgcc-compat]
extern "C" void do_nothing() __attribute__((aligned(4096))) {}
llvm-svn: 258992
This change enables diagnostics when the target address for a CFI
check is out of bounds of any known library, or even not in the
limits of the address space. This happens when casting pointers to
uninitialized memory.
Ubsan code does not yet handle some of these situations correctly,
so it is still possible to see a segmentation fault instead of a
proper diagnostic message once in a while.
llvm-svn: 258879
* add __cfi_slowpath_diag with a 3rd parameter which is a pointer to
the diagnostic info for the ubsan handlers.
*__cfi_check gets a 3rd parameter as well.
* unify vcall/cast/etc and icall diagnostic info format, and merge
the handlers to have a single entry point (actually two points due
to abort/noabort variants).
* tests
Note that this comes with a tiny overhead in the non-diag mode:
cfi_slowpath must pass 0 as the 3rd argument to cfi_check.
llvm-svn: 258744
This test requires llvm-symbolizer to be able to convert a stack
address into a function name. It is only able to do this if the
DIA SDK was found at cmake time. Add a lit feature for this,
and let the test depend on it.
See also discussion in D15363.
llvm-svn: 258545
The original submittion triggered a BFD linker bug (2.24) on Aarch64 only. Before
the build bot is upgraded to more recent linker, restrict the test to be
executed only with gold linker.
llvm-svn: 258437
Thread stack/TLS may be stored by libpthread for future reuse after
thread destruction, and the linked list it's stored in doesn't
even hold valid pointers to the objects, the latter are calculated
by obscure pointer arithmetic.
With this change applied, LSan test suite passes with
"use_ld_allocations" flag defaulted to "false". It still requires more
testing to check if the default can be switched.
llvm-svn: 257975
This is part of a new statistics gathering feature for the sanitizers.
See clang/docs/SanitizerStats.rst for further info and docs.
Differential Revision: http://reviews.llvm.org/D16176
llvm-svn: 257972
This flag allows to disable old way of determining dynamic TLS by
filtering out allocations from dynamic linker. This will be eventually
superseded by __tls_get_addr interceptor (see r257785), after we:
1) Test it in several supported environments
2) Deal with existing problems (currently we can't find a pointer to
DTV which is calloc()-ed in pthread_create).
llvm-svn: 257789
On OS X, TSan already passes all unit and lit tests, but for real-world applications (even very simple ones), we currently produce a lot of false positive reports about data races. This makes TSan useless at this point, because the noise dominates real bugs. This introduces a runtime flag, "ignore_interceptors_accesses", off by default, which makes TSan ignore all memory accesses that happen from interceptors. This will significantly lower the coverage and miss a lot of bugs, but it eliminates most of the current false positives on OS X.
Differential Revision: http://reviews.llvm.org/D15189
llvm-svn: 257760
This patch removes the requirement on stable-runtime on insertvalue_origin.cc
testcase, added due a instrumentation failure on aarch64-linux. This is fixed
on llvm code by r257375.
llvm-svn: 257479
(second try with more strict config check)
Currently, only gc-sections related tests are added. Gold
linker currently is required due to PR19161 of bfd linker.
llvm-svn: 257456
IR level instrumentation needs to override version with variant bits.
No change for FE instrumentation is needed. Test case is added to
detect version mismatch.
llvm-svn: 257230
Fix incorrect condition for enabling the CFI tests. This removes the following CMake warnings on Windows:
The dependency target "cfi" of target "check-all" does not exist.
The dependency target "cfi" of target "check-cfi-and-supported" does not exist.
llvm-svn: 257199
Summary:
In rL255491, the safestack overflow test was disabled for aarch64, since
it "is currently failing on an AArch64 buildbot with a segfault, but it
is currently passing on other configuration".
While testing on FreeBSD on x86, I also encountered a segfault. This is
because the `fct()` function actually writes before and after `buffer`,
and on FreeBSD this crashes because `buffer` is usually allocated at the
end of a page. That this runs correctly on Linux is probably just by
accident.
I propose to fix this by adding a pre and post buffer, to act as a
safety zone. The pre and post buffers must be accessed in an 'unsafe'
way, otherwise -fsanitize=safestack will allocate them on the safe
stack, and they will not bookend `buffer` itself. Therefore, I create
them large enough for `fct()`, and call it on both of them.
On FreeBSD, this makes the test run as expected, without segfaulting,
and I suppose this will also fix the segfault on AArch64. I do not have
AArch64 testing capabilities, so if someone could try that out, I would
be much obliged.
Reviewers: pcc, kcc, zatrazz
Subscribers: llvm-commits, aemerson, emaste
Differential Revision: http://reviews.llvm.org/D15725
llvm-svn: 257106
Extract the buffered filer writer code used by value profile
writer and turn it into common/sharable buffered fileIO
interfaces. Added a test case for the buffered file writer and
rewrite the VP dumping using the new APIs.
llvm-svn: 256604
Filipe Cabecinhas