| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Like r367463, but for tsan/rtl.
llvm-svn: 367564
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MmapFixedNoReserve does not terminate process on failure.
Failure to check its result and die will always lead to harder
to debug crashes later in execution. This was observed in Go
processes due to some address space conflicts.
Consistently check result of MmapFixedNoReserve.
While we are here also add warn_unused_result attribute
to prevent such bugs in future and change return type to bool
as that's what all callers want.
Reviewed in https://reviews.llvm.org/D49367
llvm-svn: 337531
|
|
|
|
|
|
|
| |
Improves crash message on dense alloc overflow.
Allows to understand what alloc overflowed.
llvm-svn: 307780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several problems with the current annotations (AnnotateRWLockCreate and friends):
- they don't fully support deadlock detection (we need a hook _before_ mutex lock)
- they don't support insertion of random artificial delays to perturb execution (again we need a hook _before_ mutex lock)
- they don't support setting extended mutex attributes like read/write reentrancy (only "linker init" was bolted on)
- they don't support setting mutex attributes if a mutex don't have a "constructor" (e.g. static, Java, Go mutexes)
- they don't ignore synchronization inside of lock/unlock operations which leads to slowdown and false negatives
The new annotations solve of the above problems. See tsan_interface.h for the interface specification and comments.
Reviewed in https://reviews.llvm.org/D31093
llvm-svn: 298809
|
|
|
|
|
|
|
|
| |
This patch allows a non-instrumented library to call into TSan runtime, and tell us about "readonly" and "modifying" accesses to an arbitrary "object" and provide the caller and tag (type of object). This allows TSan to detect violations of API threading contracts where "read-only" methods can be called simulatenously from multiple threads, while modifying methods must be exclusive.
Differential Revision: https://reviews.llvm.org/D28836
llvm-svn: 293885
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we either define SANITIZER_GO for Go or don't define it at all for C++.
This works fine with preprocessor (ifdef/ifndef/defined), but does not work
for C++ if statements (e.g. if (SANITIZER_GO) {...}). Also this is different
from majority of SANITIZER_FOO macros which are always defined to either 0 or 1.
Always define SANITIZER_GO to either 0 or 1.
This allows to use SANITIZER_GO in expressions and in flag default values.
Also remove kGoMode and kCppMode, which were meant to be used in expressions,
but they are not defined in sanitizer_common code, so SANITIZER_GO become prevalent.
Also convert some preprocessor checks to C++ if's or ternary expressions.
Majority of this change is done mechanically with:
sed "s#ifdef SANITIZER_GO#if SANITIZER_GO#g"
sed "s#ifndef SANITIZER_GO#if \!SANITIZER_GO#g"
sed "s#defined(SANITIZER_GO)#SANITIZER_GO#g"
llvm-svn: 285443
|
|
|
|
|
|
|
| |
Creating sync objects on acquire is pointless:
acquire of a just created sync object if a no-op.
llvm-svn: 273862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Unmap can't unmap arbitrary regions on windows.
llvm-svn: 267716
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current interface assumes that Go calls ProcWire/ProcUnwire
to establish the association between thread and proc.
With the wisdom of hindsight, this interface does not work
very well. I had to sprinkle Go scheduler with wire/unwire
calls, and any mistake leads to hard to debug crashes.
This is not something one wants to maintian.
Fortunately, there is a simpler solution. We can ask Go
runtime as to what is the current Processor, and that
question is very easy to answer on Go side.
Switch to such interface.
llvm-svn: 267703
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is reincarnation of http://reviews.llvm.org/D17648 with the bug fix pointed out by Adhemerval (zatrazz).
Currently ThreadState holds both logical state (required for race-detection algorithm, user-visible)
and physical state (various caches, most notably malloc cache). Move physical state in a new
Process entity. Besides just being the right thing from abstraction point of view, this solves several
problems:
Cache everything on P level in Go. Currently we cache on a mix of goroutine and OS thread levels.
This unnecessary increases memory consumption.
Properly handle free operations in Go. Frees are issue by GC which don't have goroutine context.
As the result we could not do anything more than just clearing shadow. For example, we leaked
sync objects and heap block descriptors.
This will allow to get rid of libc malloc in Go (now we have Processor context for internal allocator cache).
This in turn will allow to get rid of dependency on libc entirely.
Potentially we can make Processor per-CPU in C++ mode instead of per-thread, which will
reduce resource consumption.
The distinction between Thread and Processor is currently used only by Go, C++ creates Processor per OS thread,
which is equivalent to the current scheme.
llvm-svn: 267678
|
|
|
|
|
|
| |
Broke aarch64 and darwin bots.
llvm-svn: 262046
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently ThreadState holds both logical state (required for race-detection algorithm, user-visible)
and physical state (various caches, most notably malloc cache). Move physical state in a new
Process entity. Besides just being the right thing from abstraction point of view, this solves several
problems:
1. Cache everything on P level in Go. Currently we cache on a mix of goroutine and OS thread levels.
This unnecessary increases memory consumption.
2. Properly handle free operations in Go. Frees are issue by GC which don't have goroutine context.
As the result we could not do anything more than just clearing shadow. For example, we leaked
sync objects and heap block descriptors.
3. This will allow to get rid of libc malloc in Go (now we have Processor context for internal allocator cache).
This in turn will allow to get rid of dependency on libc entirely.
4. Potentially we can make Processor per-CPU in C++ mode instead of per-thread, which will
reduce resource consumption.
The distinction between Thread and Processor is currently used only by Go, C++ creates Processor per OS thread,
which is equivalent to the current scheme.
llvm-svn: 262037
|
|
|
|
|
|
|
| |
If user does malloc(1<<30), the write to meta shadow
can cause excessive memory consumption.
llvm-svn: 233373
|
|
|
|
|
|
|
| |
The bug was uncovered by NegativeTests.MmapTest from
data-race-test suite, so port it as well.
llvm-svn: 232032
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 217559
|
|
|
|
|
|
|
|
|
|
| |
Vector clocks is the most actively allocated object in tsan runtime.
Current internal allocator is not scalable enough to handle allocation
of clocks in scalable way (too small caches). This changes transforms
clocks to 2-level array with 512-byte blocks. Since all blocks are of
the same size, it's possible to cache them more efficiently in per-thread caches.
llvm-svn: 214912
|
|
|
|
|
|
| |
don't reset s->addr as well
llvm-svn: 212565
|
|
|
|
|
|
| |
They cause "check-tsan" command to hang. Details in r212532 review thread.
llvm-svn: 212562
|
|
|
|
|
|
| |
JVM actually moves memory between overlapping ranges.
llvm-svn: 212560
|
|
|
|
|
|
|
| |
idx0 is not updated in the branch,
so if we take that branch idx0 will stay updated forever
llvm-svn: 212532
|
|
|
|
|
|
|
|
|
| |
The bug happens in the following case:
Mutex is located at heap block beginning,
when we call MutexDestroy, s->next is set to 0,
so free can't find the MBlock related to the block.
llvm-svn: 212531
|
|
|
|
| |
llvm-svn: 211429
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new storage (MetaMap) is based on direct shadow (instead of a hashmap + per-block lists).
This solves a number of problems:
- eliminates quadratic behaviour in SyncTab::GetAndLock (https://code.google.com/p/thread-sanitizer/issues/detail?id=26)
- eliminates contention in SyncTab
- eliminates contention in internal allocator during allocation of sync objects
- removes a bunch of ad-hoc code in java interface
- reduces java shadow from 2x to 1/2x
- allows to memorize heap block meta info for Java and Go
- allows to cleanup sync object meta info for Go
- which in turn enabled deadlock detector for Go
llvm-svn: 209810
|
|
|
|
| |
llvm-svn: 204326
|
|
|
|
|
|
|
| |
intercept pthread_cond (it is required to properly track state of mutexes)
detect cycles in mutex graph
llvm-svn: 202975
|
|
|
|
|
|
|
|
| |
Introduce DDetector interface between the tool and the DD itself.
It will help to experiment with other DD implementation,
as well as reuse DD in other tools.
llvm-svn: 202485
|
|
|
|
|
|
| |
works yet except for a single tiny test). Also rename tsan's DeadlockDetector to InternalDeadlockDetector
llvm-svn: 201407
|
|
|
|
|
|
|
|
| |
This allows to increase max shadow stack size to 64K,
and reliably catch shadow stack overflows instead of silently
corrupting memory.
llvm-svn: 192797
|
|
|
|
| |
llvm-svn: 180180
|
|
|
|
| |
llvm-svn: 177312
|
|
|
|
| |
llvm-svn: 177258
|
|
|
|
| |
llvm-svn: 170707
|
|
|
|
| |
llvm-svn: 170433
|
|
|
|
|
|
| |
With this change reports say what mutexes the threads hold around the racy memory accesses.
llvm-svn: 169493
|
|
|
|
|
|
| |
time (by not memorizing full stacks in traces)
llvm-svn: 163322
|
|
|
|
| |
llvm-svn: 162169
|
|
|
|
| |
llvm-svn: 162022
|
|
|
|
| |
llvm-svn: 162021
|
|
|
|
|
|
| |
block is freed
llvm-svn: 161959
|
|
|
|
|
|
| |
reported anyway)
llvm-svn: 160861
|
|
|
|
| |
llvm-svn: 160288
|
|
|
|
|
|
| |
This improves signal-/fork-safety of instrumented programs.
llvm-svn: 158988
|
|
|
|
|
|
| |
implementations of functions. Move strchr to sanitizer_libc.
llvm-svn: 158517
|
|
|
|
| |
llvm-svn: 158260
|
|
|
|
| |
llvm-svn: 158145
|
|
|
|
| |
llvm-svn: 157928
|
|
|
|
| |
llvm-svn: 157248
|