Commit Graph

25 Commits

Author SHA1 Message Date
Dmitry Vyukov 144eafd9ee tsan: fix a crash
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
2016-05-06 19:35:22 +00:00
Alexey Samsonov a49cfd8f94 Revert "Apply modernize-use-default to compiler-rt."
This reverts commit r250823.

Replacing at least some of empty
constructors with "= default" variants is a semantical change which we
don't want. E.g. __tsan::ClockBlock contains a union of large arrays,
and it's critical for correctness and performance that we don't memset()
these arrays in the constructor.

llvm-svn: 251717
2015-10-30 18:52:31 +00:00
Angel Garcia Gomez ea61047c6f Apply modernize-use-default to compiler-rt.
Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: klimek, bkramer

Subscribers: alexfh, cfe-commits

Differential Revision: http://reviews.llvm.org/D13892

llvm-svn: 250823
2015-10-20 12:53:50 +00:00
Dmitry Vyukov 3464dac0ca tsan: speed up race deduplication
Race deduplication code proved to be a performance bottleneck in the past if suppressions/annotations are used, or just some races left unaddressed. And we still get user complaints about this:
https://groups.google.com/forum/#!topic/thread-sanitizer/hB0WyiTI4e4
ReportRace already has several layers of caching for racy pcs/addresses to make deduplication faster. However, ReportRace still takes a global mutex (ThreadRegistry and ReportMutex) during deduplication and also calls mmap/munmap (which take process-wide semaphore in kernel), this makes deduplication non-scalable.

This patch moves race deduplication outside of global mutexes and also removes all mmap/munmap calls.
As the result, race_stress.cc with 100 threads and 10000 iterations become 30x faster:

before:
real	0m21.673s
user	0m5.932s
sys	0m34.885s

after:
real	0m0.720s
user	0m23.646s
sys	0m1.254s

http://reviews.llvm.org/D12554

llvm-svn: 246758
2015-09-03 11:20:46 +00:00
Alexey Samsonov df3aeb8e71 Remove TSAN_DEBUG in favor of SANITIZER_DEBUG.
llvm-svn: 225111
2015-01-03 04:29:12 +00:00
Kostya Serebryany 83ed889bbd [tsan] remove TSAN_GO in favor of SANITIZER_GO
llvm-svn: 223732
2014-12-09 01:31:14 +00:00
Dmitry Vyukov 4f6de1d684 tsan: fix Go build with TSAN_COLLECT_STATS
Go does not have cur_thread function.

llvm-svn: 210345
2014-06-06 15:50:29 +00:00
Dmitry Vyukov bde4c9c773 tsan: refactor storage of meta information for heap blocks and sync objects
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
2014-05-29 13:50:54 +00:00
Dmitry Vyukov 6fd67f9c7a tsan: fix internal deadlock detector for external deadlock detector
we must go deeper!

llvm-svn: 202365
2014-02-27 09:02:58 +00:00
Kostya Serebryany a63632a5c6 [tsan] rudimentary support for deadlock detector in tsan (nothing really works yet except for a single tiny test). Also rename tsan's DeadlockDetector to InternalDeadlockDetector
llvm-svn: 201407
2014-02-14 12:20:42 +00:00
Dmitry Vyukov d0ac6c168b tsan: fix deadlock detector table (OK to lock sync var mutex during reporting)
llvm-svn: 180782
2013-04-30 12:00:40 +00:00
Dmitry Vyukov 22be55e47e tsan: update mutex table for java
llvm-svn: 170884
2012-12-21 11:30:14 +00:00
Dmitry Vyukov 3533f76996 tsan: completely disable deadlock detector for Go
seems to cause some weird stack overflow

llvm-svn: 170116
2012-12-13 09:22:11 +00:00
Dmitry Vyukov fd5ebcd1b0 tsan: add mutexsets to reports
With this change reports say what mutexes the threads hold around the racy memory accesses.

llvm-svn: 169493
2012-12-06 12:16:15 +00:00
Alexey Samsonov ad9d65feb8 [TSan] finally remove TsanPrintf in favor of Printf from sanitizer_common
llvm-svn: 167294
2012-11-02 12:17:51 +00:00
Alexey Samsonov 046248c509 [TSan] fix a bunch of warnings reported by pedantic gcc
llvm-svn: 163788
2012-09-13 11:54:41 +00:00
Dmitry Vyukov 191f2f7cdb tsan: use stack depot to describe heap blocks
llvm-svn: 162902
2012-08-30 13:02:30 +00:00
Dmitry Vyukov 03d32ecd4f tsan: Go language support
llvm-svn: 159754
2012-07-05 16:18:28 +00:00
Dmitry Vyukov 7a9fa7dbc5 tsan/asan: unify ScopedLock
llvm-svn: 159438
2012-06-29 17:10:08 +00:00
Alexey Samsonov 58a3c58ec9 [Sanitizer] move different wrappers from TSan to common sanitizer runtime
llvm-svn: 158655
2012-06-18 08:44:30 +00:00
Alexey Samsonov 51ae983718 [Sanitizer]: Introduce a common internal printf function. For now, also use tool-specific wrappers TsanPrintf (its output is controlled by TSan flags) and AsanPrintf (which copies its results to the ASan-private buffer). Supported formats: %[z]{d,u,x}, %s, %p. Re-write all format strings in TSan according to this format (this should have no effect on 64-bit platforms).
llvm-svn: 158065
2012-06-06 13:11:29 +00:00
Alexey Samsonov ac4c290d02 [TSan] run some renaming as a preparation for factoring out Printf implementation.
llvm-svn: 158058
2012-06-06 10:13:27 +00:00
Alexey Samsonov 3b2f9f4c98 Remove file-type tags in .cc files in tsan/ and sanitizer_common/
llvm-svn: 157928
2012-06-04 13:55:19 +00:00
Dmitry Vyukov 15710c9220 tsan: simple memory profiler
llvm-svn: 157248
2012-05-22 11:33:03 +00:00
Kostya Serebryany 4ad375f0a9 [tsan] First commit of ThreadSanitizer (TSan) run-time library.
Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm

Status:
The tool is known to work on large real-life applications, but still has quite a few rough edges.
Nothing is guaranteed yet.

The tool works on x86_64 Linux.
Support for 64-bit MacOS 10.7+ is planned for late 2012.
Support for 32-bit OSes is doable, but problematic and not yet planed.

Further commits coming:
  - tests
  - makefiles
  - documentation
  - clang driver patch

The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/
by Dmitry Vyukov and Kostya Serebryany with contributions from
Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov.

llvm-svn: 156542
2012-05-10 13:48:04 +00:00