| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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: 210301
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207954
|
|
|
|
|
|
| |
Add move fopen/freopen interceptors from TSan to common.
llvm-svn: 207224
|
|
|
|
|
|
| |
Fixes issue https://code.google.com/p/thread-sanitizer/issues/detail?id=45
llvm-svn: 207218
|
|
|
|
| |
llvm-svn: 207211
|
|
|
|
| |
llvm-svn: 207209
|
|
|
|
| |
llvm-svn: 207208
|
|
|
|
|
|
|
| |
+ fixes crashes due to races on symbolizer, see
https://code.google.com/p/thread-sanitizer/issues/detail?id=55
llvm-svn: 207206
|
|
|
|
|
|
|
| |
+ fixes crashes due to races on symbolizer, see:
https://code.google.com/p/thread-sanitizer/issues/detail?id=55
llvm-svn: 207204
|
|
|
|
|
|
| |
Fixes https://code.google.com/p/thread-sanitizer/issues/detail?id=56
llvm-svn: 207114
|
|
|
|
|
|
| |
fixes issue http://code.google.com/p/thread-sanitizer/issues/detail?id=57
llvm-svn: 206980
|
|
|
|
|
|
| |
this fires when a user makes mmap with fixed address (see the test)
llvm-svn: 206952
|
|
|
|
|
|
| |
hacks to TSan
llvm-svn: 206423
|
|
|
|
|
|
|
| |
the new optimizations break when thread ids gets reused (clocks go backwards)
add the necessary tests as well
llvm-svn: 206035
|
|
|
|
|
|
|
| |
ocassionally we see races coming from symbolizer interceptors (e.g. memcmp)
reproducible only only on large complex programs
llvm-svn: 206034
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a multi-threaded program calls fork(), TSan ignores all memory accesses
in the child to prevent deadlocks in TSan runtime. This is OK, as child is
probably going to call exec() as soon as possible. However, a rare deadlocks
could be caused by ThreadIgnoreBegin() function itself.
ThreadIgnoreBegin() remembers the current stack trace and puts it into the
StackDepot to report a warning later if a thread exited with ignores enabled.
Using StackDepotPut in a child process is dangerous: it locks a mutex on
a slow path, which could be already locked in a parent process.
The fix is simple: just don't put current stack traces to StackDepot in
ThreadIgnoreBegin() and ThreadIgnoreSyncBegin() functions if we're
running after a multithreaded fork. We will not report any
"thread exited with ignores enabled" errors in this case anyway.
Submitting this without a testcase, as I believe the standalone reproducer
is pretty hard to construct.
llvm-svn: 205534
|
|
|
|
| |
llvm-svn: 205531
|
|
|
|
| |
llvm-svn: 205316
|
|
|
|
| |
llvm-svn: 205175
|
|
|
|
|
|
| |
ReportRace takes the two mutexes in the opposite order
llvm-svn: 204809
|
|
|
|
|
|
| |
newer gcc inserts memset here
llvm-svn: 204808
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make vector clock operations O(1) for several important classes of use cases.
See comments for details.
Below are stats from a large server app, 77% of all clock operations are handled as O(1).
Clock acquire : 25983645
empty clock : 6288080
fast from release-store : 14917504
contains my tid : 4515743
repeated (fast) : 2141428
full (slow) : 2636633
acquired something : 1426863
Clock release : 2544216
resize : 6241
fast1 : 197693
fast2 : 1016293
fast3 : 2007
full (slow) : 1797488
was acquired : 709227
clear tail : 1
last overflow : 0
Clock release store : 3446946
resize : 200516
fast : 469265
slow : 2977681
clear tail : 0
Clock acquire-release : 820028
llvm-svn: 204656
|
|
|
|
| |
llvm-svn: 204655
|