summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/tsan/rtl/tsan_rtl.cc
Commit message (Collapse)AuthorAgeFilesLines
* compiler-rt: Rename .cc file in lib/tsan/rtl to .cppNico Weber2019-08-011-1099/+0
| | | | | | Like r367463, but for tsan/rtl. llvm-svn: 367564
* Improve error message when '=' is missing in {ASAN,...}_OPTIONS.Vitaly Buka2019-06-151-2/+3
| | | | | | | | | | | | | | | | | | Summary: It's handling isses as described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832 Patch by Martin Liška. Reviewers: kcc, vitalybuka Reviewed By: vitalybuka Subscribers: cryptoad, kubamracek Differential Revision: https://reviews.llvm.org/D59876 llvm-svn: 363480
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-011-8/+2
| | | | | | | | | | | | | | | | | | | | | 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-2/+8
| | | | | | This reverts commit 6112f37e758ebf2405955e091a745f5003c1f562. llvm-svn: 355171
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-011-8/+2
| | | | | | | | | | | | | | | | 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-2/+4
| | | | | | | | | | | | | 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] Fix uses of stack->Unwind(..., fast)Julian Lettner2019-02-221-1/+2
| | | | | | | | | | | Apply StackTrace::WillUseFastUnwind(fast) in a few more places missed by my previous patch (https://reviews.llvm.org/D58156). Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58550 llvm-svn: 354695
* tsan: Optimize performance of Thread sanitizer memory access functionsDmitry Vyukov2019-02-071-3/+16
| | | | | | | | | | | | | | | | - Manually unwind code in MemoryAccessImpl1() because clang do not optimize it - Check for .rodata section only in read operations - Place LIKELY/UNLIKELY on fast paths This speeds up synthetic memory access benchmarks by 10-20%. [dvyukov: fixed up consts in check_analyze.sh] Author: yuri (Yuri Per) Reviewed in: https://reviews.llvm.org/D57882 Context: https://reviews.llvm.org/D54889 llvm-svn: 353401
* 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
* [sanitizer] Use "fast mmap" kernel flag for shadow memory on macOS 10.13.4+Kuba Mracek2018-11-061-1/+3
| | | | | | | | This speeds up process startup and teardown and also reduces lock contention when running multiple ASanified/TSanified processes simultaneously. Should greatly improve lit testing time. Differential Revision: https://reviews.llvm.org/D48445 llvm-svn: 346262
* sanitizers: consistently check result of MmapFixedNoReserveDmitry Vyukov2018-07-201-8/+11
| | | | | | | | | | | | | | | | 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
* Introduce CheckASLR() in sanitizersKamil Rytarowski2018-06-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: At least the ASan, MSan, TSan sanitizers require disabled ASLR on a NetBSD. Introduce a generic CheckASLR() routine, that implements a check for the current process. This flag depends on the global or per-process settings. There is no simple way to disable ASLR in the build process from the level of a sanitizer or during the runtime execution. With ASLR enabled sanitizers that operate over the process virtual address space can misbehave usually breaking with cryptic messages. This check is dummy for !NetBSD. Sponsored by <The NetBSD Foundation> Reviewers: vitalybuka, joerg Reviewed By: vitalybuka Subscribers: cryptoad, kubamracek, llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D47442 llvm-svn: 333985
* [sanitizer] Replace InternalScopedBuffer with InternalMmapVectorVitaly Buka2018-05-071-1/+1
| | | | llvm-svn: 331618
* [sanitizer] Remove reserving constructor from InternalMmapVectorVitaly Buka2018-05-071-1/+1
| | | | llvm-svn: 331617
* tsan: disable trace switching after multithreaded forkDmitry Vyukov2018-04-301-0/+4
| | | | | | | | | | | | The problem is reported in: https://github.com/google/sanitizers/issues/945 We already disable as much as possible after multithreaded fork, trace switching is last place that can hang due to basic operations (memory accesses, function calls). Disable it too. llvm-svn: 331163
* Move __tsan::Vector to __sanitizerKamil Rytarowski2017-12-041-3/+3
| | | | | | | | | | | | | | | | | | | | | 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
* Defer StartBackgroundThread() and StopBackgroundThread() in TSanKamil Rytarowski2017-11-291-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NetBSD cannot spawn new POSIX thread entities in early libc and libpthread initialization stage. Defer this to the point of intercepting the first pthread_create(3) call. This is the last change that makes Thread Sanitizer functional on NetBSD/amd64 without downstream patches. ******************** Testing Time: 64.91s ******************** Failing Tests (5): ThreadSanitizer-x86_64 :: dtls.c ThreadSanitizer-x86_64 :: ignore_lib5.cc ThreadSanitizer-x86_64 :: ignored-interceptors-mmap.cc ThreadSanitizer-x86_64 :: mutex_lock_destroyed.cc ThreadSanitizer-x86_64 :: vfork.cc Expected Passes : 290 Expected Failures : 1 Unsupported Tests : 83 Unexpected Failures: 5 Sponsored by <The NetBSD Foundation> Reviewers: joerg, eugenis, dvyukov, vitalybuka Reviewed By: dvyukov Subscribers: kubamracek, llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D40583 llvm-svn: 319305
* [tsan] Deadly signal handler for tsanVitaly Buka2017-11-131-0/+16
| | | | | | | | | | | | Summary: https://github.com/google/sanitizers/issues/637 Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D39929 llvm-svn: 318078
* [sanitizer] Remove references and hide CommonSanitizerReportMutexVitaly Buka2017-11-101-3/+2
| | | | llvm-svn: 317865
* [sanitizer_common] Move filesystem-related code out of sanitizer_common.ccVitaly Buka2017-07-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This is a pure refactoring change. It just moves code that is related to filesystem operations from sanitizer_common.{cc,h} to sanitizer_file.{cc,h}. This makes it cleaner to disable the filesystem-related code for a new port that doesn't want it. Submitted on behalf of Roland McGrath. Reviewers: kcc, eugenis, alekseyshl Reviewed By: alekseyshl Subscribers: vitalybuka, llvm-commits, kubamracek, mgorny, phosek Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D35591 llvm-svn: 308819
* Revert "[sanitizer_common] Move filesystem-related code out of ↵Vitaly Buka2017-07-201-1/+0
| | | | | | | | | | sanitizer_common.cc" Breaks Windows build. This reverts commit r308640. llvm-svn: 308648
* [sanitizer_common] Move filesystem-related code out of sanitizer_common.ccAlex Shlyapnikov2017-07-201-0/+1
| | | | | | | | | | | | | | | | | This is a pure refactoring change. It just moves code that is related to filesystem operations from sanitizer_common.{cc,h} to sanitizer_file.{cc,h}. This makes it cleaner to disable the filesystem-related code for a new port that doesn't want it. Commiting for mcgrathr. Reviewers: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35591 llvm-svn: 308640
* tsan: give debug names to dense allocatorsDmitry Vyukov2017-07-121-1/+2
| | | | | | | Improves crash message on dense alloc overflow. Allows to understand what alloc overflowed. llvm-svn: 307780
* tsan: allow fast large MemoryRangeSet on non-Windows GoDmitry Vyukov2017-05-021-3/+2
| | | | | | | | | | | | The fast reset for large memory regions is not working only on windows. So enable it for Go/linux/darwin/freebsd. See https://github.com/golang/go/issues/20139 for background and motivation. Based on idea by Josh Bleecher Snyder. llvm-svn: 301927
* tsan: add new mutex annotationsDmitry Vyukov2017-03-261-6/+6
| | | | | | | | | | | | | | 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
* [tsan] Properly describe GCD worker threads in reportsKuba Mracek2017-02-021-1/+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] Fix os_id of main threadKuba Mracek2017-01-261-1/+1
| | | | | | | | Currently, os_id of the main thread contains the PID instead of a thread ID. Let's fix this. Differential Revision: https://reviews.llvm.org/D29106 llvm-svn: 293201
* [sanitizer] Add a 'print_module_map' flag which prints modules with UUIDs on ↵Kuba Mracek2017-01-061-0/+2
| | | | | | | | | | Darwin This patch add a new sanitizer flag, print_module_map, which enables printing a module map when the process exits, or after each report (for TSan). The output format is very similar to what Crash Reporter produces on Darwin (e.g. the format of module UUIDs). This enables users to use the existing symbol servers to offline symbolicate and aggregate reports. Differential Revision: https://reviews.llvm.org/D27400 llvm-svn: 291277
* Release memory to OS only when the requested range covers the entire pageEvgeniy Stepanov2016-11-301-3/+1
| | | | | | | | | | | | | | | | | Summary: The current code was sometimes attempting to release huge chunks of memory due to undesired RoundUp/RoundDown interaction when the requested range is fully contained within one memory page. Reviewers: eugenis Subscribers: kubabrecka, llvm-commits Patch by Aleksey Shlyapnikov. Differential Revision: https://reviews.llvm.org/D27228 llvm-svn: 288271
* tsan: mark cur_thread_placeholder definition as initial-execDmitry Vyukov2016-11-221-0/+1
| | | | | | | | | See https://sourceware.org/bugzilla/show_bug.cgi?id=20805 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294 for context. Previously we marked only declaration as initial-exec. But compilers treat initial-exec attribute somewhat differently. Mark definition as well. llvm-svn: 287629
* [tsan] Add support for C++ exceptions into TSan (call __tsan_func_exit ↵Kuba Brecka2016-11-141-0/+8
| | | | | | | | | | during unwinding), compiler-rt part This adds support for TSan C++ exception handling, where we need to add extra calls to __tsan_func_exit when a function is exitted via exception mechanisms. Otherwise the shadow stack gets corrupted (leaked). This patch moves and enhances the existing implementation of EscapeEnumerator that finds all possible function exit points, and adds extra EH cleanup blocks where needed. Differential Revision: https://reviews.llvm.org/D26177 llvm-svn: 286894
* tsan: round Go shadow to page boundaryDmitry Vyukov2016-10-281-1/+4
| | | | | | | | | | | | | There is a corner case reported in Go issue tracker: https://github.com/golang/go/issues/17065 On darwin data/bss segments may not be aligned to page bounary and mmap seems to be behaving differently than on linux (shrinks instead of enlarge unaligned regions). Explicitly round shadow to page bounary before mapping to avoid any such problems. llvm-svn: 285454
* tsan: always define SANITIZER_GODmitry Vyukov2016-10-281-27/+27
| | | | | | | | | | | | | | | | | | | | | | 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: fix code formattingDmitry Vyukov2016-10-281-1/+1
| | | | llvm-svn: 285418
* tsan: relaxed check in CheckShadowMappingDmitry Vyukov2016-09-261-2/+1
| | | | | | | | | | | | Some platforms use strange addresses in shadow mapping. E.g. aarch64/42vma: static const uptr kHiAppMemEnd = 0x3ffffffffffull; instead of 0x40000000000ull (the range is half-open). This caused bot failures after r282405: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12242/steps/ninja%20check%201/logs/FAIL%3A%20SanitizerCommon-tsan-aarch64-Linux%3A%3Aclock_gettime.c Relaxed the new check in CheckShadowMapping to not expect round addresses. llvm-svn: 282407
* tsan: make shadow mapping linear within a single user regionDmitry Vyukov2016-09-261-2/+14
| | | | | | | | | | | | | | | | | | | This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
* tsan: revert r281970Dmitry Vyukov2016-09-201-1/+1
| | | | | | | | r281970 extended the check in a useful way, but caused (true) failures on aarch64. Revert it for now. llvm-svn: 281992
* tsan: check more addresses in CheckShadowMappingDmitry Vyukov2016-09-201-1/+1
| | | | | | | | There is still a handful of them, so should not slow down tsan apps. But gives assurance if we change/complicate shadow mappings. llvm-svn: 281970
* [sanitizer] Fix darwin Go tsan build by unifying r281567 and r281553.Ahmed Bougacha2016-09-151-2/+0
| | | | | | Avoid redefining the weak stub when building gotsan.cc llvm-svn: 281576
* [tsan] fix tsan build by adding a dummy __sanitizer_print_memory_profileKostya Serebryany2016-09-141-0/+2
| | | | llvm-svn: 281553
* [asan] first attempt at releasing free-d memory back to the system using ↵Kostya Serebryany2016-08-261-1/+1
| | | | | | madvise. Requires quite some tuning. llvm-svn: 279887
* tsan: Enable 48-bit VMA support on aarch64Adhemerval Zanella2016-07-291-0/+4
| | | | | | | | | | | | | | | | | | This patch adds 48-bits VMA support for tsan on aarch64. As current mappings for aarch64, 48-bit VMA also supports PIE executable. This limits the mapping mechanism because the PIE address bits (usually 0aaaaXXXXXXXX) makes it harder to create a mask/xor value to include all memory regions. I think it is possible to create a large application VAM range by either dropping PIE support or tune current range. It also changes slight the way addresses are packed in SyncVar structure: previously it assumes x86_64 as the maximum VMA range. Since ID is 14 bits wide, shifting 48 bits should be ok. Tested on x86_64, ppc64le and aarch64 (39 and 48 bits VMA). llvm-svn: 277137
* [sanitizer] Fix a crash when demangling Swift symbols, take 3Kuba Brecka2016-05-181-2/+1
| | | | | | | | | | The previous patch (r269291) was reverted (commented out) because the patch caused leaks that were detected by LSan and they broke some lit tests. The actual reason was that dlsym allocates an error string buffer in TLS, and some LSan lit tests are intentionally not scanning TLS for root pointers. This patch simply makes LSan ignore the allocation from dlsym, because it's not interesting anyway. llvm-svn: 269917
* [sanitizers] disabling LateInitialize call to fix the build.Mike Aizatsky2016-05-171-1/+2
| | | | | | | | http://reviews.llvm.org/rL269291 introduced a memory leak. Disabling offending call temprorary rather than rolling back the chain of CLs. llvm-svn: 269799
* Fixup for r269291, which broke the Go TSan build. Let's not use the ↵Kuba Brecka2016-05-121-0/+2
| | | | | | symbolizer in Go builds. llvm-svn: 269293
* [sanitizer] Fix a crash when demangling Swift symbols, take 2Kuba Brecka2016-05-121-0/+2
| | | | | | | | | | To invoke the Swift demangler, we use dlsym to locate swift_demangle. However, dlsym malloc's storage and stores it in thread-local storage. Since allocations from the symbolizer are done with the system allocator (at least in TSan, interceptors are skipped when inside the symbolizer), we will crash when we try to deallocate later using the sanitizer allocator again. To fix this, let's just not call dlsym from the demangler, and call it during initialization. The dlsym function calls malloc, so it needs to be only used after our allocator is initialized. Adding a Symbolizer::LateInitialize call that is only invoked after all other initializations. Differential Revision: http://reviews.llvm.org/D20015 llvm-svn: 269291
* tsan: fix a crashDmitry Vyukov2016-05-061-0/+1
| | | | | | | | | | | | | 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
* [sanitizer] [SystemZ] Abort if the kernel might be vulnerable to CVE-2016-2143.Marcin Koscielnicki2016-04-271-0/+1
| | | | | | | | | | | | | | | | | | In short, CVE-2016-2143 will crash the machine if a process uses both >4TB virtual addresses and fork(). ASan, TSan, and MSan will, by necessity, map a sizable chunk of virtual address space, which is much larger than 4TB. Even worse, sanitizers will always use fork() for llvm-symbolizer when a bug is detected. Disable all three by aborting on process initialization if the running kernel version is not known to contain a fix. Unfortunately, there's no reliable way to detect the fix without crashing the kernel. So, we rely on whitelisting - I've included a list of upstream kernel versions that will work. In case someone uses a distribution kernel or applied the fix themselves, an override switch is also included. Differential Revision: http://reviews.llvm.org/D19576 llvm-svn: 267747
* tsan: split thread into logical and physical stateDmitry Vyukov2016-04-271-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud