summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc
Commit message (Collapse)AuthorAgeFilesLines
* compiler-rt: Rename .cc file in lib/tsan/rtl to .cppNico Weber2019-08-011-756/+0
| | | | | | Like r367463, but for tsan/rtl. llvm-svn: 367564
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-011-9/+3
| | | | | | | | | | | | | | | | | | | | | Retrying without replacing call sites in sanitizer_common (which might not have a symbol definition). Add new Unwind API. This is the final envisioned API with the correct abstraction level. It hides/slow fast unwinder selection from the caller and doesn't take any arguments that would leak that abstraction (i.e., arguments like stack_top/stack_bottom). GetStackTrace will become an implementation detail (private method) of the BufferedStackTrace class. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58741 > llvm-svn: 355168 llvm-svn: 355172
* Revert "[NFC][Sanitizer] Add new BufferedStackTrace::Unwind API"Julian Lettner2019-03-011-3/+9
| | | | | | This reverts commit 6112f37e758ebf2405955e091a745f5003c1f562. llvm-svn: 355171
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-011-9/+3
| | | | | | | | | | | | | | | | Add new Unwind API. This is the final envisioned API with the correct abstraction level. It hides/slow fast unwinder selection from the caller and doesn't take any arguments that would leak that abstraction (i.e., arguments like stack_top/stack_bottom). GetStackTrace will become an implementation detail (private method) of the BufferedStackTrace class. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58741 llvm-svn: 355168
* [NFC][Sanitizer] Hard-code fast/slow unwinder at call siteJulian Lettner2019-02-271-5/+6
| | | | | | | | | | | | | Also assert that the caller always gets what it requested. This purely mechanical change simplifies future refactorings and eventual removal of BufferedStackTrace::Unwind. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58557 llvm-svn: 355022
* [Sanitizer] On Darwin `__sanitizer_print_stack_trace` only prints topmost frameJulian Lettner2019-02-181-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In compiler-rt we have the notion of a `fast` and a `slow` stack unwinder. Darwin currently only supports the fast unwinder. From reading the code, my understanding is that `BufferedStackTrace::Unwind` can be called with `bp=0, stack_top=0, stack_bottom=0, request_fast_unwind=false`. If `request_fast_unwind=true`, then we alos need to supply bp, stack_top, and stack_bottom. However, `BufferedStackTrace::Unwind` uses `StackTrace::WillUseFastUnwind` which will adapt `request_fast_unwind` if the requested unwinder is not supported. On Darwin, the result is that we don't pass actual values for bp, stack_top, and stack_bottom, but end up using the fast unwinder. The tests then fail because we only print the topmost stack frame. This patch adds a check to `WillUseFastUnwind` at the point of usage to avoid the mismatch between `request_fast_unwind` and what `Unwind` actually does. I am also interested in cleaning up the `request_fast_unwind` machinery so this patch just the simplest thing possible so I can enable the tests. Reviewers: vitalybuka, vsk Differential Revision: https://reviews.llvm.org/D58156 llvm-svn: 354282
* sanitizers: Introduce ThreadType enumDmitry Vyukov2019-02-071-1/+1
| | | | | | | | | | | | | Replace bool workerthread flag with ThreadType enum. This change is preparation for fiber support. [dvyukov: fixed build of sanitizer_thread_registry_test.cc] Author: yuri (Yuri Per) Reviewed in: https://reviews.llvm.org/D57839 Context: https://reviews.llvm.org/D54889 llvm-svn: 353390
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* tsan: support inlined frames in external symbolizationDmitry Vyukov2018-03-211-2/+2
| | | | | | | | | | | | New API passes a callback function to the external symbolizer, allowing it to add multiple frames to the traceback. Note that the old interface API will be still supported until the clients migrate to the new one. Author: asmundak (Alexander Smundak) Reviewed in: https://reviews.llvm.org/D44714 llvm-svn: 328079
* Move __tsan::Vector to __sanitizerKamil Rytarowski2017-12-041-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: The low-fat STL-like vector container will be reused in MSan. It is needed to implement an atexit(3) interceptor on NetBSD/amd64 in MSan. Sponsored by <The NetBSD Foundation> Reviewers: joerg, dvyukov, eugenis, vitalybuka, kcc Reviewed By: dvyukov Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D40726 llvm-svn: 319650
* [sanitizer] Remove references and hide CommonSanitizerReportMutexVitaly Buka2017-11-101-21/+20
| | | | llvm-svn: 317865
* tsan: don't pass bogus PCs to __tsan_symbolize_externalDmitry Vyukov2017-08-251-3/+23
| | | | | | | | See the added comment for an explanation. Reviewed in https://reviews.llvm.org/D37107 llvm-svn: 311768
* tsan: s/-1/kInvalidTid/Dmitry Vyukov2017-07-121-1/+1
| | | | llvm-svn: 307781
* [tsan] Detect races on modifying accesses in Swift codeKuba Mracek2017-05-031-5/+12
| | | | | | | | This patch allows the Swift compiler to emit calls to `__tsan_external_write` before starting any modifying access, which will cause TSan to detect races on arrays, dictionaries and other classes defined in non-instrumented modules. Races on collections from the Swift standard library and user-defined structs and a frequent cause of subtle bugs and it's important that TSan detects those on top of existing LLVM IR instrumentation, which already detects races in direct memory accesses. Differential Revision: https://reviews.llvm.org/D31630 llvm-svn: 302050
* [tsan] Track external tags in thread tracesKuba Mracek2017-04-301-6/+10
| | | | | | | | To make the TSan external API work with Swift and other use cases, we need to track "tags" for individual memory accesses. Since there is no space to store this information in shadow cells, let's use the thread traces for that. This patch stores the tag as an extra frame in the stack traces (by calling FuncEntry and FuncExit with the address of a registered tag), this extra frame is then stripped before printing the backtrace to stderr. Differential Revision: https://reviews.llvm.org/D32382 llvm-svn: 301777
* [tsan] Don't report bugs from interceptors called from libignored modulesKuba Mracek2017-04-211-1/+1
| | | | | | | | This patch make sure we don't report deadlocks and other bug types when we're inside an interceptor that was called from a noninstrumented module (when ignore_noninstrumented_modules=1 is set). Adding a testcase that shows that deadlock detection still works on Darwin (to make sure we're not silencing too many reports). Differential Revision: https://reviews.llvm.org/D31449 llvm-svn: 300998
* [tsan] Provide API for libraries for race detection on custom objectsKuba Mracek2017-02-021-3/+8
| | | | | | | | 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
* [tsan] Properly describe GCD worker threads in reportsKuba Mracek2017-02-021-0/+1
| | | | | | | | When dealing with GCD worker threads, TSan currently prints weird things like "created by thread T-1" and "[failed to restore the stack]" in reports. This patch avoids that and instead prints "Thread T3 (...) is a GCD worker thread". Differential Revision: https://reviews.llvm.org/D29103 llvm-svn: 293882
* tsan: always define SANITIZER_GODmitry Vyukov2016-10-281-8/+8
| | | | | | | | | | | | | | | | | | | | | | 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
* tsan: make CHECK more robustDmitry Vyukov2016-09-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable more ignores when we start crashing. Unwind in CHECK SIGSEGVs if happens early: FATAL: ThreadSanitizer CHECK failed: ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:105 "((beg)) <= ((end))" (0x8000000000, 0x4000000000) Program received signal SIGSEGV, Segmentation fault. __tsan::MetaMap::GetAndLock (this=0x1337c88 <__tsan::ctx_placeholder+8>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true, create=create@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:208 208 u32 idx0 = *meta; (gdb) bt #0 __tsan::MetaMap::GetAndLock (this=0x1337c88 <__tsan::ctx_placeholder+8>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true, create=create@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:208 #1 0x00000000004a965f in __tsan::MetaMap::GetOrCreateAndLock (this=<optimized out>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:198 #2 0x00000000004a162a in __tsan::Release (thr=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:395 #3 0x000000000046cc40 in __interceptor_pthread_once (o=0x7ffff71a5890 <once_regsizes>, f=0x7ffff6f9d9c0 <init_dwarf_reg_size_table>) at ../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1334 #4 0x00007ffff6f9fe86 in __gthread_once (__func=0x7ffff6f9d9c0 <init_dwarf_reg_size_table>, __once=0x7ffff71a5890 <once_regsizes>) at ./gthr-default.h:699 #5 uw_init_context_1 (context=context@entry=0x7fffffffd6d0, outer_cfa=outer_cfa@entry=0x7fffffffd980, outer_ra=0x437d13 <__sanitizer::BufferedStackTrace::SlowUnwindStack(unsigned long, unsigned int)+67>) at ../../../src/libgcc/unwind-dw2.c:1572 #6 0x00007ffff6fa06a8 in _Unwind_Backtrace (trace=0x437c30 <__sanitizer::Unwind_Trace(_Unwind_Context*, void*)>, trace_argument=0x7fffffffd980) at ../../../src/libgcc/unwind.inc:283 #7 0x0000000000437d13 in __sanitizer::BufferedStackTrace::SlowUnwindStack (this=0x7ffff6103208, pc=pc@entry=4863574, max_depth=max_depth@entry=256) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:125 #8 0x0000000000434f4a in __sanitizer::BufferedStackTrace::Unwind (this=this@entry=0x7ffff6103208, max_depth=max_depth@entry=256, pc=pc@entry=4863574, bp=bp@entry=0, context=context@entry=0x0, stack_top=stack_top@entry=0, stack_bottom=stack_bottom@entry=0, request_fast_unwind=request_fast_unwind@entry=false) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc:76 #9 0x00000000004a36b3 in PrintCurrentStackSlow (pc=4863574) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc:696 #10 __tsan::TsanCheckFailed (file=<optimized out>, line=<optimized out>, cond=<optimized out>, v1=<optimized out>, v2=<optimized out>) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc:44 #11 0x000000000042dfd6 in __sanitizer::CheckFailed (file=file@entry=0x4b9fd0 "../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc", line=line@entry=105, cond=cond@entry=0x4ba049 "((beg)) <= ((end))", v1=v1@entry=549755813888, v2=v2@entry=274877906944) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79 #12 0x00000000004aa36c in ProtectRange (end=274877906944, beg=549755813888) at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:105 #13 __tsan::CheckAndProtect () at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:133 #14 0x00000000004a9e95 in __tsan::InitializePlatform () at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_linux.cc:280 #15 0x0000000000497e73 in __tsan::Initialize (thr=0x7ffff7f91800) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl.cc:343 #16 0x00007ffff7dea25a in _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffdb88, env=0x7fffffffdb98) at dl-init.c:111 #17 0x00007ffff7ddb30a in _dl_start_user () at rtld.c:871 llvm-svn: 281969
* tsan: don't create sync objects on acquireDmitry Vyukov2016-06-271-1/+1
| | | | | | | Creating sync objects on acquire is pointless: acquire of a just created sync object if a no-op. llvm-svn: 273862
* [tsan] Rename ReportThread->pid to ReportThread->os_idKuba Brecka2016-04-211-1/+1
| | | | | | | | 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
* Always inlining PrintCurrentStackSlow of tsan library to fix tail-call issueChuang-Yu Cheng2016-04-201-0/+8
| | | | | | | | | | | | | | | | | | | | The real problem is that sanitizer_print_stack_trace obtains current PC and expects the PC to be in the stack trace after function calls. We don't prevent tail calls in sanitizer runtimes, so this assumption does not necessary hold. We add "always inline" attribute on PrintCurrentStackSlow to address this issue, however this solution is not reliable enough, but unfortunately, we don't see any simple, reliable solution. Reviewers: samsonov hfinkel kbarton tjablin dvyukov kcc http://reviews.llvm.org/D19148 Thanks Hal, dvyukov, and kcc for invaluable discussion, I have even borrowed part of dvyukov's summary as my commit message! llvm-svn: 266869
* [tsan] Add TSan debugger APIsKuba Brecka2016-03-101-1/+12
| | | | | | | | Currently, TSan only reports everything in a formatted textual form. The idea behind this patch is to provide a consistent API that can be used to query information contained in a TSan-produced report. User can use these APIs either in a debugger (via a script or directly), or they can use it directly from the process (e.g. in the __tsan_on_report callback). ASan already has a similar API, see http://reviews.llvm.org/D4466. Differential Revision: http://reviews.llvm.org/D16191 llvm-svn: 263126
* tsan: describe heap/data locations in GoDmitry Vyukov2016-03-011-1/+1
| | | | llvm-svn: 262343
* [TSan] Try harder to avoid compiler-generated memset calls.Alexey Samsonov2015-12-091-3/+3
| | | | | | | | | | check_memcpy test added in r254959 fails on some configurations due to memset() calls inserted by Clang. Try harder to avoid them: * Explicitly use internal_memset() instead of empty braced-initializer. * Replace "new T()" with "new T", as the former generates zero-initialization for structs in C++11. llvm-svn: 255136
* [tsan] Fix weakly imported functions on OS XKuba Brecka2015-11-301-2/+2
| | | | | | | | | | On OS X, for weak function (that user can override by providing their own implementation in the main binary), we need extern `"C" SANITIZER_INTERFACE_ATTRIBUTE SANITIZER_WEAK_ATTRIBUTE NOINLINE`. Fixes a broken test case on OS X, java_symbolization.cc, which uses a weak function __tsan_symbolize_external. Differential Revision: http://reviews.llvm.org/D14907 llvm-svn: 254298
* [tsan] Fix an assertion failure in FindThreadByUidLocked with recycled threadsKuba Brecka2015-11-281-8/+8
| | | | | | | | | | | | When a race on file descriptors is detected, `FindThreadByUidLocked()` is called to retrieve ThreadContext with a specific unique_id. However, this ThreadContext might not exist in the thread registry anymore (it may have been recycled), in which case `FindThreadByUidLocked` will cause an assertion failure in `GetThreadLocked`. Adding a test case that reproduces this, producing: FATAL: ThreadSanitizer CHECK failed: sanitizer_common/sanitizer_thread_registry.h:92 "((tid)) < ((n_contexts_))" (0x34, 0x34) This patch fixes this by replacing the loop with `FindThreadContextLocked`. Differential Revision: http://reviews.llvm.org/D14984 llvm-svn: 254223
* tsan: speed up race deduplicationDmitry Vyukov2015-09-031-76/+83
| | | | | | | | | | | | | | | | | | | | | | | 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
* [TSan] Support __sanitizer_set_death_callback().Alexey Samsonov2015-08-221-1/+1
| | | | llvm-svn: 245776
* [Sanitizers] Unify the semantics and usage of "exitcode" runtime flag across ↵Alexey Samsonov2015-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | all sanitizers. Summary: Merge "exitcode" flag from ASan, LSan, TSan and "exit_code" from MSan into one entity. Additionally, make sure sanitizer_common now uses the value of common_flags()->exitcode when dying on error, so that this flag will automatically work for other sanitizers (UBSan and DFSan) as well. User-visible changes: * "exit_code" MSan runtime flag is now deprecated. If explicitly specified, this flag will take precedence over "exitcode". The users are encouraged to migrate to the new version. * __asan_set_error_exit_code() and __msan_set_exit_code() functions are removed. With few exceptions, we don't support changing runtime flags during program execution - we can't make them thread-safe. The users should use __sanitizer_set_death_callback() that would call _exit() with proper exit code instead. * Plugin tools (LSan and UBSan) now inherit the exit code of the parent tool. In particular, this means that ASan would now crash the program with exit code "1" instead of "23" if it detects leaks. Reviewers: kcc, eugenis Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12120 llvm-svn: 245734
* tsan: don't report any bugs when report_bugs=0 flag is setDmitry Vyukov2015-08-211-0/+2
| | | | llvm-svn: 245720
* tsan: always subtract one from program countersDmitry Vyukov2015-02-141-6/+0
| | | | | | | | Go has a pending change to pass proper PCs to tsan: https://go-review.googlesource.com/#/c/4902/ So now we can always subtract one from PCs. llvm-svn: 229262
* tsan: fix styleDmitry Vyukov2014-12-231-3/+2
| | | | | | Usually we roll the variable declaration into the condition in cases like this. llvm-svn: 224755
* tsan: fix debugging outputDmitry Vyukov2014-12-221-2/+2
| | | | llvm-svn: 224701
* tsan: don't crash with NULL deref during reportingDmitry Vyukov2014-12-181-1/+3
| | | | | | | | tctx==NULL crash observed during deadlock reporting. There seems to be some bugs in the deadlock detector, but it is still useful to be more robust during reporting. llvm-svn: 224508
* tsan: don't subtract one from fake PCsDmitry Vyukov2014-12-111-2/+3
| | | | | | | These are fake and not actual PCs, more like function IDs. Pass them to external symbolizer untouched. llvm-svn: 224022
* [tsan] remove TSAN_GO in favor of SANITIZER_GOKostya Serebryany2014-12-091-8/+8
| | | | llvm-svn: 223732
* Simplify Symbolizer::SymbolizePC() interface.Alexey Samsonov2014-12-021-30/+26
| | | | | | | | | | | Return a linked list of AddressInfo objects, instead of using an array of these objects as an output parameter. This simplifies the code in callers of this function (especially TSan). Fix a few memory leaks from internal allocator, when the returned AddressInfo objects were not properly cleared. llvm-svn: 223145
* [Sanitizer] Introduce "stack_trace_format" runtime flag.Alexey Samsonov2014-11-061-3/+12
| | | | | | | | | | | | | | | | This flag can be used to specify the format of stack frames - user can now provide a string with placeholders, which should be printed for each stack frame with placeholders replaced with actual data. For example "%p" will be replaced by PC, "%s" will be replaced by the source file name etc. "DEFAULT" value enforces default stack trace format currently used in all the sanitizers except TSan. This change also implements __sanitizer_print_stack_trace interface function in TSan. llvm-svn: 221469
* [TSan] Refactor/simplify ReportLocation structure.Alexey Samsonov2014-11-041-20/+10
| | | | | | | | | | | | # Make DataInfo (describing a global) a member of ReportLocation to avoid unnecessary copies and allocations. # Introduce a constructor and a factory method, so that all structure users don't have to go to internal allocator directly. # Remove unused fields (file/line). No functionality change. llvm-svn: 221302
* [TSan] Make ReportStack contain __sanitizer::AddressInfo object.Alexey Samsonov2014-11-041-8/+11
| | | | | | | | | | AddressInfo contains the results of symbolization. Store this object directly in the symbolized stack, instead of copying data around and making unnecessary memory allocations. No functionality change. llvm-svn: 221294
* [TSan] Keep original function and filename in ReportStack.Alexey Samsonov2014-11-041-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | TSan used to do the following transformations with data obtained from the symbolizer: 1) Strip "__interceptor_" prefix from function name. 2) Use "strip_path_prefix" runtime flag to strip filepath. Now these transformations are performed right before the stack trace is printed, and ReportStack structure contains original information. This seems like a right thing to do - stripping is a detail of report formatting implementation, and should belong there. We should, for example, use original path to source file when we apply suppressions. This change also make "strip_path_prefix" flag behavior in TSan consistent with all the other sanitizers - now it should actually match *the prefix* of path, not some substring. E.g. earlier TSan would turn "/usr/lib/libfoo.so" into "libfoo.so" even if strip_path_prefix was "/lib/". Finally, strings obtained from symbolizer come from internal allocator, and "stripping" them early by incrementing a "char*" ensures they can never be properly deallocated, which is a bug. llvm-svn: 221283
* [TSan] Use StackTrace from sanitizer_common where applicableAlexey Samsonov2014-11-031-47/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change removes `__tsan::StackTrace` class. There are now three alternatives: # Lightweight `__sanitizer::StackTrace`, which doesn't own a buffer of PCs. It is used in functions that need stack traces in read-only mode, and helps to prevent unnecessary allocations/copies (e.g. for StackTraces fetched from StackDepot). # `__sanitizer::BufferedStackTrace`, which stores buffer of PCs in a constant array. It is used in TraceHeader (non-Go version) # `__tsan::VarSizeStackTrace`, which owns buffer of PCs, dynamically allocated via TSan internal allocator. Test Plan: compiler-rt test suite Reviewers: dvyukov, kcc Reviewed By: kcc Subscribers: llvm-commits, kcc Differential Revision: http://reviews.llvm.org/D6004 llvm-svn: 221194
* [Sanitizer] Make StackTrace a lightweight reference to array of PCs, andAlexey Samsonov2014-10-261-9/+9
| | | | | | | | | | | | | | | | | | | | | | introduce a BufferedStackTrace class, which owns this array. Summary: This change splits __sanitizer::StackTrace class into a lightweight __sanitizer::StackTrace, which doesn't own array of PCs, and BufferedStackTrace, which owns it. This would allow us to simplify the interface of StackDepot, and eventually merge __sanitizer::StackTrace with __tsan::StackTrace. Test Plan: regression test suite. Reviewers: kcc, dvyukov Reviewed By: dvyukov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5985 llvm-svn: 220635
* tsan: better reporting for virtual-call-after-freeDmitry Vyukov2014-10-131-1/+3
| | | | | | | Previously we said that it's a data race, which is confusing if it happens in the same thread. llvm-svn: 219600
* [TSan] Use common flags in the same way as all the other sanitizersAlexey Samsonov2014-09-101-1/+1
| | | | llvm-svn: 217559
* tsan: remove special handling of false reports coming from JVMDmitry Vyukov2014-07-151-38/+0
| | | | | | There is now a more common functionality in the form of called_from_lib suppressions. llvm-svn: 213057
* tsan: remove compat mappingDmitry Vyukov2014-07-151-2/+1
| | | | | | There are no known usages anymore, so one less thing to support. llvm-svn: 213056
* tsan: refactor storage of meta information for heap blocks and sync objectsDmitry Vyukov2014-05-291-13/+27
| | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud