| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
JVM actually moves memory between overlapping ranges.
llvm-svn: 212560
|
|
|
|
|
|
|
|
| |
The tsan's deadlock detector has been used in Chromium for a while;
it found a few real bugs and reported no false positives.
So, it's time to give it a bit more exposure.
llvm-svn: 212533
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
(https://code.google.com/p/thread-sanitizer/issues/detail?id=67)
llvm-svn: 212529
|
|
|
|
|
|
| |
deadlocks when reporting bad unlock
llvm-svn: 212526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce new public header <sanitizer/allocator_interface.h> and a set
of functions __sanitizer_get_ownership(), __sanitizer_malloc_hook() etc.
that will eventually replace their tool-specific equivalents
(__asan_get_ownership(), __msan_get_ownership() etc.). Tool-specific
functions are now deprecated and implemented as stubs redirecting
to __sanitizer_ versions (which are implemented differently in each tool).
Replace all uses of __xsan_ versions with __sanitizer_ versions in unit
and lit tests.
llvm-svn: 212469
|
|
|
|
| |
llvm-svn: 212322
|
|
|
|
|
|
|
|
|
|
|
| |
user_alloc_usable_size.
The former used to crash with a null deref if it was given a not owned pointer,
while the latter returned 0. Now they both return 0. This is still not the best possible
behavior: it is better to print an error report with a stack trace, pointing
to the error in user code, as we do in ASan.
llvm-svn: 212112
|
|
|
|
|
|
|
| |
It is required to prevent false positives between object ctor and finalizer,
as otherwise they look completely unsynchronized.
llvm-svn: 211829
|
|
|
|
| |
llvm-svn: 211429
|
|
|
|
| |
llvm-svn: 211422
|
|
|
|
| |
llvm-svn: 211419
|
|
|
|
| |
llvm-svn: 211418
|
|
|
|
| |
llvm-svn: 211389
|
|
|
|
| |
llvm-svn: 211386
|
|
|
|
|
|
| |
This is a resubmit of r211166 reverted due to osx breakage.
llvm-svn: 211264
|
|
|
|
|
|
| |
This reverts commit r211166. It broke public mac os x bots.
llvm-svn: 211206
|
|
|
|
| |
llvm-svn: 211166
|
|
|
|
|
|
| |
Go calling convention does not support bools (it probably works, but uptrs are safer)
llvm-svn: 210365
|
|
|
|
|
|
| |
FuncEnter adds FuncEnter entry to trace that nobody removes later
llvm-svn: 210359
|
|
|
|
|
|
| |
In Go it's legal to unlock from a different goroutine.
llvm-svn: 210358
|
|
|
|
| |
llvm-svn: 210353
|
|
|
|
| |
llvm-svn: 210351
|
|
|
|
|
|
| |
FuncEntry can resize the shadow stack, while "thr->shadow_stack_pos[0] = pc" writes out-of-bounds.
llvm-svn: 210349
|
|
|
|
|
|
|
| |
Go maps heap and data+bss, these regions are not adjacent.
data+bss is mapped first.
llvm-svn: 210348
|
|
|
|
| |
llvm-svn: 210347
|
|
|
|
|
|
| |
comparison of unsigned expression >= 0 is always true
llvm-svn: 210346
|
|
|
|
|
|
| |
Go does not have cur_thread function.
llvm-svn: 210345
|
|
|
|
| |
llvm-svn: 210344
|
|
|
|
| |
llvm-svn: 210301
|
|
|
|
| |
llvm-svn: 210232
|
|
|
|
|
|
| |
Based on a patch by Stephan Bergmann.
llvm-svn: 210199
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The optimization is two-fold:
First, the algorithm now uses SSE instructions to
handle all 4 shadow slots at once. This makes processing
faster.
Second, if shadow contains the same access, we do not
store the event into trace. This increases effective
trace size, that is, tsan can remember up to 10x more
previous memory accesses.
Perofrmance impact:
Before:
[ OK ] DISABLED_BENCH.Mop8Read (2461 ms)
[ OK ] DISABLED_BENCH.Mop8Write (1836 ms)
After:
[ OK ] DISABLED_BENCH.Mop8Read (1204 ms)
[ OK ] DISABLED_BENCH.Mop8Write (976 ms)
But this measures only fast-path.
On large real applications the speedup is ~20%.
Trace size impact:
On app1:
Memory accesses : 1163265870
Including same : 791312905 (68%)
on app2:
Memory accesses : 166875345
Including same : 150449689 (90%)
90% of filtered events means that trace size is effectively 10x larger.
llvm-svn: 209897
|
|
|
|
|
|
|
|
|
|
| |
e.g.:
RSS 420 MB: shadow:35 meta:231 file:2 mmap:129 trace:19 heap:0 other:0 nthr=1/31
RSS 365 MB: shadow:3 meta:231 file:2 mmap:106 trace:19 heap:0 other:0 nthr=1/31
RSS 429 MB: shadow:23 meta:234 file:2 mmap:143 trace:19 heap:6 other:0 nthr=1/31
RSS 509 MB: shadow:78 meta:241 file:2 mmap:147 trace:19 heap:19 other:0 nthr=1/31
llvm-svn: 209813
|
|
|
|
| |
llvm-svn: 209811
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
The refactoring makes suppressions more flexible
and allow to suppress based on arbitrary number of stacks.
In particular it fixes:
https://code.google.com/p/thread-sanitizer/issues/detail?id=64
"Make it possible to suppress deadlock reports by any stack (not just first)"
llvm-svn: 209757
|
|
|
|
|
|
| |
64-bit atomics make porting of asan to 32-bits platforms problematic.
llvm-svn: 209744
|
|
|
|
| |
llvm-svn: 209658
|
|
|
|
|
|
|
|
|
|
|
| |
This way does not require a __sanitizer_cov_dump() call. That's
important on Android, where apps can be killed at arbitrary time.
We write raw PCs to disk instead of module offsets; we also write
memory layout to a separate file. This increases dump size by the
factor of 2 on 64-bit systems.
llvm-svn: 209653
|
|
|
|
| |
llvm-svn: 209476
|
|
|
|
| |
llvm-svn: 209286
|
|
|
|
| |
llvm-svn: 209003
|
|
|
|
|
|
|
| |
The mode is enabled with -DTSAN_NO_HISTORY=1 flag.
Intended mostly for research purposes (how fast can it go w/o history).
llvm-svn: 208878
|
|
|
|
| |
llvm-svn: 208841
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TSan can produce false positives in code that uses C++11 threading,
as it doesn't see synchronization inside standard library. See
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-February/035408.html
for an example of such case.
We may build custom TSan-instrumented version libcxx to fight with that.
This change adds build rules for libcxx_tsan and integrates it into
testing infrastructure.
llvm-svn: 208737
|
|
|
|
|
|
|
|
| |
Move fflush and fclose interceptors to sanitizer_common.
Use a metadata map to keep information about the external locations
that must be updated when the file is written to.
llvm-svn: 208676
|
|
|
|
|
|
| |
that we don't depend on the compiler flags
llvm-svn: 208536
|
|
|
|
| |
llvm-svn: 208207
|