This patch adds assembly routines to enable setjmp/longjmp for aarch64
on linux. It fixes:
* test/tsan/longjmp2.cc
* test/tsan/longjmp3.cc
* test/tsan/longjmp4.cc
* test/tsan/signal_longjmp.cc
I also checked with perlbench from specpu2006 (it fails to run
with missing setjmp/longjmp intrumentation).
llvm-svn: 253205
Fixing `tsan_interceptors.cc`, which on OS X produces a bunch of warnings about unused constants and functions.
Differential Revision: http://reviews.llvm.org/D14381
llvm-svn: 252165
On OS X, memcpy and memmove are actually aliases of the same implementation, which means the interceptor of memcpy is also invoked when memmove is called. The current implementation of the interceptor uses `internal_memcpy` to perform the actual memory operation, which can produce an incorrect result when memmove semantics are expected. Let's call `internal_memmove` instead.
Differential Revision: http://reviews.llvm.org/D14336
llvm-svn: 252162
A call to memmove is used early during new thread initialization on OS X. This patch uses the `COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED` check, similarly to how we deal with other early-used interceptors.
Differential Revision: http://reviews.llvm.org/D14377
llvm-svn: 252161
TSan has a re-implementation of `pthread_once` in its interceptor, which assumes that the `pthread_once_t *once_control` pointer is actually pointing to a "storage" which is zero-initialized and used for the atomic operations. However, that's not true on OS X, where pthread_once_t is a structure, that contains a header (with a magic value) and the actual storage follows after that. This patch skips the header to make the interceptor work on OS X.
Differential Revision: http://reviews.llvm.org/D14379
llvm-svn: 252160
This implements a "poor man's TLV" to be used for TSan's ThreadState on OS X. Based on the fact that `pthread_self()` is always available and reliable and returns a valid pointer to memory, we'll use the shadow memory of this pointer as a thread-local storage. No user code should ever read/write to this internal libpthread structure, so it's safe to use it for this purpose. We lazily allocate the ThreadState object and store the pointer here.
Differential Revision: http://reviews.llvm.org/D14288
llvm-svn: 252159
TSan needs to use a custom malloc zone on OS X, which is already implemented in ASan. This patch uses the sanitizer_common implementation in `sanitizer_malloc_mac.inc` for TSan as well.
Reviewed at http://reviews.llvm.org/D14330
llvm-svn: 252155
On OS X, GCD worker threads are created without a call to pthread_create. We need to properly register these threads with ThreadCreate and ThreadStart. This patch uses a libpthread API (`pthread_introspection_hook_install`) to get notifications about new threads and about threads that are about to be destroyed.
Differential Revision: http://reviews.llvm.org/D14328
llvm-svn: 252049
This patch modifies `tsan_interceptors.cc` to be buildable on OS X. Several of the intercepted methods are not available on OS X, so we need to `#if !SANITIZER_MAC` them. Plus a few other fixes, e.g. `pthread_yield` doesn't exist, let's use `internal_sched_yield` instead.
This is part of an effort to port TSan to OS X, and it's one the very first steps. Don't expect TSan on OS X to actually work or pass tests at this point.
Differential Revision: http://reviews.llvm.org/D14237
llvm-svn: 251916
Race deduplication code proved to be a performance bottleneck in the past if suppressions/annotations are used, or just some races left unaddressed. And we still get user complaints about this:
https://groups.google.com/forum/#!topic/thread-sanitizer/hB0WyiTI4e4
ReportRace already has several layers of caching for racy pcs/addresses to make deduplication faster. However, ReportRace still takes a global mutex (ThreadRegistry and ReportMutex) during deduplication and also calls mmap/munmap (which take process-wide semaphore in kernel), this makes deduplication non-scalable.
This patch moves race deduplication outside of global mutexes and also removes all mmap/munmap calls.
As the result, race_stress.cc with 100 threads and 10000 iterations become 30x faster:
before:
real 0m21.673s
user 0m5.932s
sys 0m34.885s
after:
real 0m0.720s
user 0m23.646s
sys 0m1.254s
http://reviews.llvm.org/D12554
llvm-svn: 246758
This patch enabled TSAN for aarch64 with 39-bit VMA layout. As defined by
tsan_platform.h the layout used is:
0000 4000 00 - 0200 0000 00: main binary
2000 0000 00 - 4000 0000 00: shadow memory
4000 0000 00 - 5000 0000 00: metainfo
5000 0000 00 - 6000 0000 00: -
6000 0000 00 - 6200 0000 00: traces
6200 0000 00 - 7d00 0000 00: -
7d00 0000 00 - 7e00 0000 00: heap
7e00 0000 00 - 7fff ffff ff: modules and main thread stack
Which gives it about 8GB for main binary, 4GB for heap and 8GB for
modules and main thread stack.
Most of tests are passing, with the exception of:
* ignore_lib0, ignore_lib1, ignore_lib3 due a kernel limitation for
no support to make mmap page non-executable.
* longjmp tests due missing specialized assembly routines.
These tests are xfail for now.
The only tsan issue still showing is:
rtl/TsanRtlTest/Posix.ThreadLocalAccesses
Which still required further investigation. The test is disable for
aarch64 for now.
llvm-svn: 244055
Summary:
PTHREAD_CREATE_DETACHED has a different value on Mac OS X. Since both
PTHREAD_CREATE_JOINABLE and PTHREAD_CREATE_DETACHED are non-zero,
`__tsan::ThreadCreate` always creates detached threads.
Reviewers: kcc, samsonov, glider
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10606
llvm-svn: 243151
POSIX states that "It shall be safe to destroy an initialized condition
variable upon which no threads are currently blocked", and later clarifies
"A condition variable can be destroyed immediately after all the threads
that are blocked on it are awakened) (in examples section). Tsan reported
such destruction as a data race.
Fixes https://llvm.org/bugs/show_bug.cgi?id=23616
Reviewed in http://reviews.llvm.org/D10693
llvm-svn: 241082
Previously tsan modelled dup2(oldfd, newfd) as write on newfd.
We hit several cases where the write lead to false positives:
1. Some software dups a closed pipe in place of a socket before closing
the socket (to prevent races actually).
2. Some daemons dup /dev/null in place of stdin/stdout.
On the other hand we have not seen cases when write here catches real bugs.
So model dup2 as read on newfd instead.
llvm-svn: 240687
We see false reports between dlopen and dl_iterate_phdr.
This happens because tsan does not see dynamic linker
internal synchronization. Unpoison module names
in dl_iterate_phdr callback.
llvm-svn: 240576
Current code tries to find the dynamic TLS header to the left of the
TLS block without checking that it's not a static TLS allocation.
llvm-svn: 237495
Fixes https://llvm.org/bugs/show_bug.cgi?id=23235
If pthread_create is followed by pthread_detach,
the new thread may not acquire synchronize with
the parent thread.
llvm-svn: 235293
This patch is related to Issue 346: moar string interceptors: strstr, strcasestr, strcspn, strpbrk
As was suggested in original review http://reviews.llvm.org/D6056 a new "strict_string_checks" run-time flag introduced.
The flag support applied for existing common, asan, msan and tsan interceptors. New asan tests added.
Change by Maria Guseva reviewed in http://reviews.llvm.org/D7123
llvm-svn: 234187
MetaMap::ResetRange/FreeRange rounds the range up to at least kMetaShadowSize.
This is requried for e.g. free(malloc(0)). However, munmap returns EINVAL
and do not unmap any memory when length arguments is equal to 0.
So don't free meta shadow in this case as well.
llvm-svn: 234145
Munmap interceptor did not reset meta shadow for the range,
and __tsan_java_move crashed because it encountered
non-zero meta shadow for the destination.
llvm-svn: 232029
The problem is that without SA_RESTORER flag, kernel ignores the handler. So tracer actually did not setup any handler.
Add SA_RESTORER flag when setting up handlers.
Add a test that causes SIGSEGV in stoptheworld callback.
Move SignalContext from asan to sanitizer_common to print better diagnostics about signal in the tracer thread.
http://reviews.llvm.org/D8005
llvm-svn: 230978
SuppressionContext is no longer a singleton, shared by all sanitizers,
but a regular class. Each of ASan, LSan, UBSan and TSan now have their
own SuppressionContext, which only parses suppressions specific to
that sanitizer.
"suppressions" flag is moved away from common flags into tool-specific
flags, so the user now may pass
ASAN_OPTIONS=suppressions=asan_supp.txt LSAN_OPIONS=suppressions=lsan_supp.txt
in a single invocation.
llvm-svn: 230026
Let each LibIgnore user (for now it's only TSan) manually go
through SuppressionContext and pass ignored library templates to
LibIgnore.
llvm-svn: 229924
signal handler reads sa_sigaction when a concurrent sigaction call can modify it
as the result in could try to call SIG_DFL or a partially overwritten function pointer
llvm-svn: 224530
Summary:
Turn "allocator_may_return_null" common flag into an
Allocator::may_return_null bool flag. We want to make sure
that common flags are immutable after initialization. There
are cases when we want to change this flag in the allocator
at runtime: e.g. in unit tests and during ASan activation
on Android.
Test Plan: regression test suite, real-life applications
Reviewers: kcc, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6623
llvm-svn: 224148
Adhemerval Zanella