| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
4.1+ Linux kernels map pie binaries at 0x55:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90
Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503).
Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb).
This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb.
This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping.
llvm-svn: 282152
|
|
|
|
| |
llvm-svn: 281821
|
|
|
|
| |
llvm-svn: 281820
|
|
|
|
| |
llvm-svn: 281462
|
|
|
|
|
|
|
|
| |
This patch adds a wrapper for call_once, which uses an already-compiled helper __call_once with an atomic release which is invisible to TSan. To avoid false positives, the interceptor performs an explicit atomic release in the callback wrapper.
Differential Revision: https://reviews.llvm.org/D24188
llvm-svn: 280920
|
|
|
|
|
|
|
| |
The map32bit.cc test uses the MMAP_32BIT flag which is supported only
on x86-64.
llvm-svn: 280084
|
|
|
|
|
|
|
| |
Reviewed by dvyukov
Differential: https://reviews.llvm.org/D23494
llvm-svn: 278775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
default.
Summary:
The triple is not the right thing to XFAIL on since LIT only sees the default
triple and not the effective triple chosen by any -target option in the RUN
directives. This discrepancy is shown in the table below:
Default Triple | Options | XFAIL | LIT's expected result | Desired expectation
=================+===================================+========+=======================+====================
mips-linux-gnu | -target mips-linux-gnu | | Pass | Pass
mips-linux-gnu | -target mips64-linux-gnu -mabi=64 | | Pass | Pass
mips-linux-gnu | -target mips-linux-gnu | mips | Fail | Fail
mips-linux-gnu | -target mips64-linux-gnu -mabi=64 | mips | Fail | Fail/Pass* (debatable**)
mips-linux-gnu | -target mips-linux-gnu | mips- | Fail | Fail
mips-linux-gnu | -target mips64-linux-gnu -mabi=64 | mips- | Fail | Pass*
mips-linux-gnu | -target mips-linux-gnu | mips64 | Pass | Pass
mips-linux-gnu | -target mips64-linux-gnu -mabi=64 | mips64 | Pass | Fail*
mips64-linux-gnu | -target mips-linux-gnu | | Pass | Pass
mips64-linux-gnu | -target mips64-linux-gnu -mabi=64 | | Pass | Pass
mips64-linux-gnu | -target mips-linux-gnu | mips | Fail | Fail*
mips64-linux-gnu | -target mips64-linux-gnu -mabi=64 | mips | Fail | Fail/Pass (debatable**)
mips64-linux-gnu | -target mips-linux-gnu | mips- | Pass | Fail*
mips64-linux-gnu | -target mips64-linux-gnu -mabi=64 | mips- | Pass | Pass
mips64-linux-gnu | -target mips-linux-gnu | mips64 | Fail | Pass*
mips64-linux-gnu | -target mips64-linux-gnu -mabi=64 | mips64 | Fail | Fail
x64_64-linux-gnu | -target i386-linux-gnu | | Pass | Pass
x64_64-linux-gnu | -target x86_64-linux-gnu | | Pass | Pass
x64_64-linux-gnu | -target i386-linux-gnu | i386 | Pass | Fail*
x64_64-linux-gnu | -target x86_64-linux-gnu | i386 | Pass | Pass
x64_64-linux-gnu | -target i386-linux-gnu | x86_64 | Fail | Pass
x64_64-linux-gnu | -target x86_64-linux-gnu | x86_64 | Fail | Fail*
* These all differ from LIT's current behaviour.
** People's expectations vary depending on whether they know that LIT does a
substring match on the default triple or think it's an exact match on an
architecture.
This patch adds "target-is-${target_arch}" to the available features list and
updates the mips XFAIL's to use them. XFAIL'ing on these features will
correctly account for the target being tested. Making the table:
Options | XFAIL | LIT's expected result
==================================+==================+======================
-target mips-linux-gnu | | Pass
-target mips64-linux-gnu -mabi=64 | | Pass
-target mips-linux-gnu | target-is-mips | Fail
-target mips64-linux-gnu -mabi=64 | target-is-mips | Pass
-target mips-linux-gnu | target-is-mips64 | Pass
-target mips64-linux-gnu -mabi=64 | target-is-mips64 | Fail
-target i386-linux-gnu | | Pass
-target x86_64-linux-gnu | | Pass
-target i386-linux-gnu | target-is-i386 | Fail
-target x86_64-linux-gnu | target-is-i386 | Pass
-target i386-linux-gnu | target-is-x86_64 | Pass
-target x86_64-linux-gnu | target-is-x86_64 | Fail
Reviewers: probinson
Subscribers: probinson, kubabrecka, llvm-commits, samsonov
Differential Revision: https://reviews.llvm.org/D22802
llvm-svn: 278116
|
|
|
|
|
|
|
|
| |
The system implementation of OSAtomicTestAndClear returns the original bit, but the TSan interceptor has a bug which always returns zero from the function. This patch fixes this and adds a test.
Differential Revision: https://reviews.llvm.org/D23061
llvm-svn: 277461
|
|
|
|
|
|
|
|
| |
On Darwin, there are some apps that rely on realloc(nullptr, 0) returning a valid pointer. TSan currently returns nullptr in this case, let's fix it to avoid breaking binary compatibility.
Differential Revision: https://reviews.llvm.org/D22800
llvm-svn: 277458
|
|
|
|
|
|
|
|
|
|
| |
When we delay signals we can deliver them when the signal
is blocked. This can be surprising to the program.
Intercept signal blocking functions merely to process
pending signals. As the result, at worst we will delay
a signal till return from the signal blocking function.
llvm-svn: 276876
|
|
|
|
|
|
| |
being deadlocked.
llvm-svn: 275182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
|
|
|
|
|
|
|
|
| |
This patch adds interceptors for dispatch_io_*, dispatch_read and dispatch_write functions. This avoids false positives when using GCD IO. Adding several test cases.
Differential Revision: http://reviews.llvm.org/D21889
llvm-svn: 275071
|
|
|
|
|
|
|
|
|
|
| |
These test in this change are objc++, but are built using %clang, not %clangxx.
The reason this works is the driver has been adding -lc++ for sanitizer enabled
builds. By making these tests use %clangxx, they no longer depend on the driver
linking to c++. Doing so will allow us to prevent overlinking of libc++ for
applications.
llvm-svn: 274989
|
|
|
|
|
|
|
|
| |
This patch adds synchronization between the creation of the GCD data object and destructor’s execution. It’s far from perfect, because ideally we’d want to synchronize the destruction of the last reference (via dispatch_release) and the destructor’s execution, but intercepting objc_release is problematic.
Differential Revision: http://reviews.llvm.org/D21990
llvm-svn: 274749
|
|
|
|
|
|
|
|
| |
We already have interceptors for dispatch_source API (e.g. dispatch_source_set_event_handler), but they currently only handle submission synchronization. We also need to synchronize based on the target queue (serial, concurrent), in other words, we need to use dispatch_callback_wrap. This patch implements that.
Differential Revision: http://reviews.llvm.org/D21999
llvm-svn: 274619
|
|
|
|
|
|
|
|
| |
In the patch that introduced support for GCD barrier blocks, I removed releasing a group when leaving it (in dispatch_group_leave). However, this is necessary to synchronize leaving a group and a notification callback (dispatch_group_notify). Adding this back, simplifying dispatch_group_notify_f and adding a test case.
Differential Revision: http://reviews.llvm.org/D21927
llvm-svn: 274549
|
|
|
|
|
|
|
|
|
|
| |
original dispatch_once is used
Because we use SCOPED_TSAN_INTERCEPTOR in the dispatch_once interceptor, the original dispatch_once can also be sometimes called (when ignores are enabled or when thr->is_inited is false). However the original dispatch_once function doesn’t expect to find “2” in the storage and it will spin forever (but we use “2” to indicate that the initialization is already done, so no waiting is necessary). This patch makes sure we never call the original dispatch_once.
Differential Revision: http://reviews.llvm.org/D21976
llvm-svn: 274548
|
|
|
|
|
|
| |
flaky because it's detecting a false positive race (coming from a system library) and sometimes that race is detected after we're printing "Done".
llvm-svn: 274346
|
|
|
|
|
|
|
|
| |
The dispatch_group_async interceptor actually extends the lifetime of the executed block. This means the destructor of the block (and captured variables) is called *after* dispatch_group_leave, which changes the semantics of dispatch_group_async. This patch fixes that.
Differential Revision: http://reviews.llvm.org/D21816
llvm-svn: 274117
|
|
|
|
|
|
| |
Obj-C/Darwin tests currently need this to avoid false positives.
llvm-svn: 274014
|
|
|
|
|
|
|
|
| |
Adding support for GCD barrier blocks in concurrent queues. This uses two sync object in the same way as read-write locks do. This also simplifies the use of dispatch groups (the notifications act as barrier blocks).
Differential Revision: http://reviews.llvm.org/D21604
llvm-svn: 273893
|
|
|
|
|
|
|
|
|
|
| |
weak_ptrs and destructors in C++
There is a "well-known" TSan false positive when using C++ weak_ptr/shared_ptr and code in destructors, e.g. described at <https://llvm.org/bugs/show_bug.cgi?id=22324>. The "standard" solution is to build and use a TSan-instrumented version of libcxx, which is not trivial for end-users. This patch tries a different approach (on OS X): It adds an interceptor for the specific function in libc++.dylib, which implements the atomic operation that needs to be visible to TSan.
Differential Revision: http://reviews.llvm.org/D21609
llvm-svn: 273806
|
|
|
|
|
|
|
|
|
| |
The new annotation was added a while ago, but was not actually used.
Use the annotation to detect linker-initialized mutexes instead
of the broken IsGlobalVar which has both false positives and false
negatives. Remove IsGlobalVar mess.
llvm-svn: 271663
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the added test produces false race reports with glibc 2.19,
because DLTS memory is reused by pthread under the hood.
Use the DTLS machinery to intercept new DTLS ranges.
__tls_get_addr known to cause issues for tsan in the past,
so write the interceptor more carefully.
Reviewed in http://reviews.llvm.org/D20927
llvm-svn: 271568
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Some libraries, like OpenSSL, runs code from .init section.
Reviewers: kcc, eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D20646
llvm-svn: 270873
|
|
|
|
|
|
| |
explicitly.
llvm-svn: 270713
|
|
|
|
|
|
|
|
| |
In one of the already existing apps that I'm testing TSan on, I really see a mutex path that is longer than 10 (but not by much, something like 11-13 actually). Let's raise this to 20 and weaken the assertion so we don't crash.
Differential Revision: http://reviews.llvm.org/D20427
llvm-svn: 270319
|
|
|
|
|
|
|
|
| |
We're missing interceptors for dispatch_after and dispatch_after_f. Let's add them to avoid false positives. Added a test case.
Differential Revision: http://reviews.llvm.org/D20426
llvm-svn: 270071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ignore_interceptors_accesses setting did not have an effect on mmap, so
let's change that. It helps in cases user code is accessing the memory
written to by mmap when the synchronization is ensured by the code that
does not get rebuilt.
(This effects Swift interoperability since it's runtime is mapping memory
which gets accessed by the code emitted into the Swift application by the
compiler.)
Differential Revision: http://reviews.llvm.org/D20294
llvm-svn: 269855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another stack where we try to free sync objects,
but don't have a processors is:
// ResetRange
// __interceptor_munmap
// __deallocate_stack
// start_thread
// clone
Again, it is a latent bug that lead to memory leaks.
Also, increase amount of memory we scan in MetaMap::ResetRange.
Without that the test does not fail, as we fail to free
the sync objects on stack.
llvm-svn: 269041
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes crash reported in:
https://bugs.chromium.org/p/v8/issues/detail?id=4995
The problem is that we don't have a processor in a free interceptor
during thread exit.
The crash was introduced by introduction of Processors.
However, previously we silently leaked memory which wasn't any better.
llvm-svn: 268782
|
|
|
|
|
|
|
|
| |
In http://reviews.llvm.org/D19100, I introduced a bug: On OS X, existing programs rely on malloc_size() to detect whether a pointer comes from heap memory (malloc_size returns non-zero) or not. We have to distinguish between a zero-sized allocation (where we need to return 1 from malloc_size, due to other binary compatibility reasons, see http://reviews.llvm.org/D19100), and pointers that are not returned from malloc at all.
Differential Revision: http://reviews.llvm.org/D19653
llvm-svn: 268157
|
|
|
|
|
|
|
|
| |
The field "pid" in ReportThread is used to store the OS-provided thread ID (pthread_self or gettid). The name "pid" suggests it's a process ID, which it isn't. Let's rename it.
Differential Revision: http://reviews.llvm.org/D19365
llvm-svn: 266994
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Removed unwanted --check-prefix=CHECK from the following unit tests:
test/asan/TestCases/Posix/start-deactivated.cc
test/tsan/Darwin/ignored-interceptors.mm
Patch by: Mandeep Singh Grang (mgrang)
Reviewers: samsonov, kcc, dvyukov, eugenis
Differential Revision: http://reviews.llvm.org/D19281
llvm-svn: 266813
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment almost every lit.site.cfg.in contains two lines comment:
## Autogenerated by LLVM/Clang configuration.
# Do not edit!
The patch adds variable LIT_SITE_CFG_IN_HEADER, that is replaced from
configure_lit_site_cfg with the note and some useful information.
llvm-svn: 266520
|
|
|
|
|
|
|
|
| |
Some tests didn't merge stderr with stdout.
Patch by Maxim Kuvyrkov.
llvm-svn: 266426
|
|
|
|
|
|
| |
This reverts commit r266294, as it broke some buildbots again. :/
llvm-svn: 266300
|
|
|
|
|
|
|
|
|
| |
Using stderr more uniformily, avoiding potential races when scanning stdout
and stderr output.
Patch by Maxim Kuvyrkov.
llvm-svn: 266294
|
|
|
|
|
|
|
|
| |
The custom zone implementation for OS X must not return 0 (even for 0-sized allocations). Returning 0 indicates that the pointer doesn't belong to the zone. This can break existing applications. The underlaying allocator allocates 1 byte for 0-sized allocations anyway, so returning 1 in this case is okay.
Differential Revision: http://reviews.llvm.org/D19100
llvm-svn: 266283
|
|
|
|
| |
llvm-svn: 265919
|
|
|
|
|
|
|
|
| |
On one of our testing machines, we're running the tests under heavy load, and especially in the fork-based TSan tests, we're seeing timeouts when a test uses sleep(10), assuming that calling fork() on another thread will finish sooner than that. This patch removes a timeout and makes another one longer.
Differential Revision: http://reviews.llvm.org/D18476
llvm-svn: 265666
|
|
|
|
|
|
|
|
| |
OS X provides atomic functions in libkern/OSAtomic.h. These provide atomic guarantees and they have alternatives which have barrier semantics. This patch adds proper TSan support for the functions from libkern/OSAtomic.h.
Differential Revision: http://reviews.llvm.org/D18500
llvm-svn: 265665
|
|
|
|
|
|
|
|
| |
Adding an interceptor with two more release+acquire pairs to avoid false positives with dispatch_apply.
Differential Revision: http://reviews.llvm.org/D18722
llvm-svn: 265662
|
|
|
|
|
|
|
|
| |
XPC APIs have async callbacks, and we need some more happen-before edges to avoid false positives. This patch add them, plus a test case (sorry for the long boilerplate code, but XPC just needs all that).
Differential Revision: http://reviews.llvm.org/D18493
llvm-svn: 265661
|
|
|
|
|
|
|
|
| |
GCD has APIs for event sources, we need some more release-acquire pairs to avoid false positives in TSan.
Differential Revision: http://reviews.llvm.org/D18515
llvm-svn: 265660
|
|
|
|
|
|
|
|
| |
In the interceptor for dispatch_sync, we're currently missing synchronization between the callback and the code *after* the call to dispatch_sync. This patch fixes this by adding an extra release+acquire pair to dispatch_sync() and similar APIs. Added a testcase.
Differential Revision: http://reviews.llvm.org/D18502
llvm-svn: 265659
|
|
|
|
|
|
|
|
| |
A little embarrassing, but we're missing the call to FileCheck in several Darwin tests. Let's fix this.
Differential Revision: http://reviews.llvm.org/D18503
llvm-svn: 265658
|
|
|
|
|
|
| |
ignore_interceptors_accesses=1 for GCD tests and printf instead of NSLog).
llvm-svn: 265300
|