| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
This patch fixes the custom ThreadState destruction on OS X to avoid crashing when dispatch_main calls pthread_exit which quits the main thread.
Differential Revision: http://reviews.llvm.org/D18496
llvm-svn: 264627
|
|
|
|
|
|
| |
to the common interceptors")
llvm-svn: 264571
|
|
|
|
| |
llvm-svn: 264271
|
|
|
|
|
|
|
|
| |
On OS X, fork() under TSan asserts (in debug builds only) because REAL(fork) calls some intercepted functions, which check that no internal locks are held via CheckNoLocks(). But the wrapper of fork intentionally holds some locks. This patch fixes that by using ScopedIgnoreInterceptors during the call to REAL(fork). After that, all the fork-based tests seem to pass on OS X, so let's just remove all the UNSUPPORTED: darwin annotations we have.
Differential Revision: http://reviews.llvm.org/D18409
llvm-svn: 264261
|
|
|
|
|
|
|
|
| |
On OS X, internal_mmap just uses mmap, which can invoke callbacks into libmalloc (e.g. when MallocStackLogging is enabled). This can subsequently call other intercepted functions, and this breaks our Darwin-specific ThreadState initialization. Let's use direct syscalls in internal_mmap and internal_munmap. Added a testcase.
Differential Revision: http://reviews.llvm.org/D18431
llvm-svn: 264259
|
|
|
|
|
|
| |
Depending on the version of libcxx, nullptr might not be available. Let's use NULL instead.
llvm-svn: 264058
|
|
|
|
|
|
| |
the debugging API")
llvm-svn: 263946
|
|
|
|
|
|
| |
race_on_mutex.c passes for powerpc64le too after revision 263778. So removing the XFAIL marker.
llvm-svn: 263779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stack trace produced by TSan on MIPS is:
Previous write of size 8 at 0x0120ed2930 by thread T1:
#0 memset
/home/slt/LLVM/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:678
(race_on_mutex.c.tmp+0x0120071808)
#1 __GI___pthread_mutex_init
/build/glibc-g99ldr/glibc-2.19/nptl/pthread_mutex_init.c:84
(libpthread.so.0+0x000000d634)
#2 <null>
/home/slt/LLVM/llvm/projects/compiler-rt/test/tsan/race_on_mutex.c:11 (race_on_mutex.c.tmp+0x01200ea59c)
Reviewers: samsonov, dvyukov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D17796
llvm-svn: 263778
|
|
|
|
|
|
|
|
|
|
| |
On OS X 10.11+, we have "automatic interceptors", so we don't need to use DYLD_INSERT_LIBRARIES when launching instrumented programs. However, non-instrumented programs that load TSan late (e.g. via dlopen) are currently broken, as TSan will still try to initialize, but the program will crash/hang at random places (because the interceptors don't work). This patch adds an explicit check that interceptors are working, and if not, it aborts and prints out an error message suggesting to explicitly use DYLD_INSERT_LIBRARIES.
TSan unit tests run with a statically linked runtime, where interceptors don't work. To avoid aborting the process in this case, the patch replaces `DisableReexec()` with a weak `ReexecDisabled()` function which is defined to return true in unit tests.
Differential Revision: http://reviews.llvm.org/D18212
llvm-svn: 263695
|
|
|
|
|
|
|
|
| |
This patch adds a new TSan report type, ReportTypeMutexInvalidAccess, which is triggered when pthread_mutex_lock or pthread_mutex_unlock returns EINVAL (this means the mutex is invalid, uninitialized or already destroyed).
Differential Revision: http://reviews.llvm.org/D18132
llvm-svn: 263641
|
|
|
|
| |
llvm-svn: 263553
|
|
|
|
|
|
|
|
| |
On OS X 10.11+, we have "automatic interceptors", so we don't need to use DYLD_INSERT_LIBRARIES when launching instrumented programs. However, non-instrumented programs that load TSan late (e.g. via dlopen) are currently broken, as TSan will still try to initialize, but the program will crash/hang at random places (because the interceptors don't work). This patch adds an explicit check that interceptors are working, and if not, it aborts and prints out an error message suggesting to explicitly use DYLD_INSERT_LIBRARIES.
Differential Revision: http://reviews.llvm.org/D18121
llvm-svn: 263551
|
|
|
|
|
|
| |
(nil) or (null) on different platforms.
llvm-svn: 263137
|
|
|
|
|
|
|
|
| |
Currently, TSan only reports everything in a formatted textual form. The idea behind this patch is to provide a consistent API that can be used to query information contained in a TSan-produced report. User can use these APIs either in a debugger (via a script or directly), or they can use it directly from the process (e.g. in the __tsan_on_report callback). ASan already has a similar API, see http://reviews.llvm.org/D4466.
Differential Revision: http://reviews.llvm.org/D16191
llvm-svn: 263126
|
|
|
|
|
|
|
|
|
| |
setuid(0) hangs on powerpc64 big endian. When this is fixed remove
the unsupported flag.
https://llvm.org/bugs/show_bug.cgi?id=25799
llvm-svn: 262814
|
|
|
|
|
|
| |
Fix blank lines.
llvm-svn: 262689
|
|
|
|
|
|
|
|
|
| |
The test case compiler-rt/test/tsan/java_race_pc.cc fails on powerpc64
big endian but not little endian.
Add missing blank line.
llvm-svn: 262675
|
|
|
|
|
|
|
| |
The test case compiler-rt/test/tsan/java_race_pc.cc fails on powerpc64
big endian but not little endian.
llvm-svn: 262669
|
|
|
|
|
|
|
|
|
| |
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 reverts commit r262476, as it broken the AArch64 VMA42 buildbot.
llvm-svn: 262479
|
|
|
|
|
|
|
|
| |
by avoiding potential races when scanning stdout and stderr output.
Patch by Maxim Kuvyrkov.
llvm-svn: 262476
|
|
|
|
| |
llvm-svn: 262000
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
The test case compiler-rt/test/tsan/ignore_lib4.cc fails on powerpc64
big endian but not little endian.
llvm-svn: 261900
|
|
|
|
|
|
|
|
|
|
| |
Fails on bots:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/1555/steps/ninja%20check%201/logs/FAIL%3A%20ThreadSanitizer-powerpc64%3A%3A%20ignore_lib4.cc
http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/725/steps/ninja%20check-tsan/logs/stdio
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/1468/steps/ninja%20check%202/logs/FAIL%3A%20ThreadSanitizer-aarch64%3A%3A%20ignore_lib4.cc
http://lab.llvm.org:8011/builders/clang-native-aarch64-full/builds/2787/steps/ninja%20check%202/logs/FAIL%3A%20ThreadSanitizer-aarch64%3A%3A%20ignore_lib4.cc
llvm-svn: 261728
|
|
|
|
| |
llvm-svn: 261660
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 261601
|
|
|
|
| |
llvm-svn: 261148
|
|
|
|
| |
llvm-svn: 261142
|
|
|
|
|
|
|
|
|
|
| |
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 is now a default name_suffix ('default') which should appease the buildbot
and reveal why this builder lacks a suffix.
llvm-svn: 260679
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 259650
|
|
|
|
|
|
| |
This also reverts r259577 which was a quick-fix to fix buildbots.
llvm-svn: 259593
|
|
|
|
| |
llvm-svn: 259544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
${TSAN_SUPPORTED_ARCH}.
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
|
|
|
|
| |
llvm-svn: 259529
|
|
|
|
|
|
|
|
|
| |
${TSAN_SUPPORTED_ARCH}.
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
|
|
|
|
|
|
|
| |
This test case which worked for a while is now failing again. I was unable to
trace the change in status to any particular revision.
llvm-svn: 258739
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Somebody reported flakiness of this test.
Let's start by checking errors.
llvm-svn: 257585
|
|
|
|
|
|
|
| |
Several test cases that used to fail on both power LE and BE
now run correctly on LE.
llvm-svn: 256391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds PIE executable support for aarch64-linux. It adds
two more segments:
- 0x05500000000-0x05600000000: 39-bits PIE program segments
- 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments
Fortunately it is possible to use the same transformation formula for
the new segments range with some adjustments in shadow to memory
formula (it adds a constant offset based on the VMA size).
A simple testcase is also added, however it is disabled on x86 due the
fact it might fail on newer kernels [1].
[1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90
llvm-svn: 256184
|
|
|
|
|
|
|
|
|
|
| |
We're using the dispatch group itself to synchronize (to call Release() and Acquire() on it), but in dispatch group notifications, the group can already be disposed/deallocated. This causes a later assertion failure at `DCHECK_EQ(*meta, 0);` in `MetaMap::AllocBlock` when the same memory is reused (note that the failure only happens in debug builds).
Fixing this by retaining the group and releasing it in the notification. Adding a stress test case that reproduces this.
Differential Revision: http://reviews.llvm.org/D15380
llvm-svn: 255494
|
|
|
|
|
|
|
| |
Several test cases that used to fail on both power LE and BE
now run correctly on LE.
llvm-svn: 255262
|
|
|
|
| |
llvm-svn: 255076
|