summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/tsan
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[sanitizer] Move *fstat to the common interceptors"Mike Aizatsky2016-05-171-0/+54
| | | | | | This reverts commit http://reviews.llvm.org/rL269856 llvm-svn: 269863
* [sanitizer] Move *fstat to the common interceptorsMike Aizatsky2016-05-171-54/+0
| | | | | | | | | | | | | | | | Summary: Adds *fstat to the common interceptors. Removes the now-duplicate fstat interceptor from msan/tsan This adds fstat to asan/esan, which previously did not intercept it. Reviewers: eugenis, vitalybuka, aizatsky Subscribers: tberghammer, danalbert, srhines, kubabrecka, bruening, kcc Differential Revision: http://reviews.llvm.org/D20318 llvm-svn: 269856
* [tsan] Ensure mmap respects ignore_interceptors_accessesAnna Zaks2016-05-171-2/+10
| | | | | | | | | | | | | | | The ignore_interceptors_accesses setting did not have an effect on mmap, so let's change that. It helps in cases user code is accessing the memory written to by mmap when the synchronization is ensured by the code that does not get rebuilt. (This effects Swift interoperability since it's runtime is mapping memory which gets accessed by the code emitted into the Swift application by the compiler.) Differential Revision: http://reviews.llvm.org/D20294 llvm-svn: 269855
* [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
* [sanitizer] Move *stat to the common interceptorsEvgeniy Stepanov2016-05-111-73/+0
| | | | | | | | | | | Adds *stat to the common interceptors. Removes the now-duplicate *stat interceptor from msan/tsan/esan. This adds *stat to asan, which previously did not intercept it. Patch by Qin Zhao. llvm-svn: 269223
* tsan: fix another crash due to processorsDmitry Vyukov2016-05-104-23/+52
| | | | | | | | | | | | | | | | | | Another stack where we try to free sync objects, but don't have a processors is: // ResetRange // __interceptor_munmap // __deallocate_stack // start_thread // clone Again, it is a latent bug that lead to memory leaks. Also, increase amount of memory we scan in MetaMap::ResetRange. Without that the test does not fail, as we fail to free the sync objects on stack. llvm-svn: 269041
* tsan: fix a crashDmitry Vyukov2016-05-067-0/+43
| | | | | | | | | | | | | 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] Move stat/__xstat to the common interceptorsMike Aizatsky2016-05-031-25/+0
| | | | | | | | | | | | | | | | | | Summary: Adds stat/__xstat to the common interceptors. Removes the now-duplicate stat/__xstat interceptor from msan/tsan/esan. This adds stat/__xstat to asan, which previously did not intercept it. Resubmit of http://reviews.llvm.org/D19875 with win build fixes. Reviewers: aizatsky, eugenis Subscribers: tberghammer, llvm-commits, danalbert, vitalybuka, bruening, srhines, kubabrecka, kcc Differential Revision: http://reviews.llvm.org/D19890 llvm-svn: 268466
* Revert "[sanitizer] Move stat/__xstat to the common interceptors"Mike Aizatsky2016-05-031-0/+25
| | | | | | | | This reverts commit 268440 because it breaks the windows bot. http://lab.llvm.org:8011/builders/sanitizer-windows/builds/21425/steps/build%20compiler-rt/logs/stdio llvm-svn: 268448
* [sanitizer] Move stat/__xstat to the common interceptorsMike Aizatsky2016-05-031-25/+0
| | | | | | | | | | | | | | | | Summary: Adds stat/__xstat to the common interceptors. Removes the now-duplicate stat/__xstat interceptor from msan/tsan/esan. This adds stat/__xstat to asan, which previously did not intercept it. Reviewers: aizatsky, eugenis Subscribers: tberghammer, danalbert, srhines, kubabrecka, llvm-commits, vitalybuka, eugenis, kcc, bruening Differential Revision: http://reviews.llvm.org/D19875 llvm-svn: 268440
* tsan: update tsan_analyze to what tip clang generatesDmitry Vyukov2016-05-031-14/+2
| | | | | | | | | | | | We used to depend on host gcc. But some distributions got new gcc recently which broke the check. Generally, we can't depend that an arbitrary host gcc generates something stable. Switch to clang. This has an additional advantage of catching regressions in clang codegen. llvm-svn: 268382
* [tsan] Return 0 from malloc_size for non-malloc'd pointersKuba Brecka2016-04-302-3/+6
| | | | | | | | In http://reviews.llvm.org/D19100, I introduced a bug: On OS X, existing programs rely on malloc_size() to detect whether a pointer comes from heap memory (malloc_size returns non-zero) or not. We have to distinguish between a zero-sized allocation (where we need to return 1 from malloc_size, due to other binary compatibility reasons, see http://reviews.llvm.org/D19100), and pointers that are not returned from malloc at all. Differential Revision: http://reviews.llvm.org/D19653 llvm-svn: 268157
* [tsan] Fix Darwin GCD support after separation of Processor and ThreadStateKuba Brecka2016-04-281-1/+3
| | | | | | Recent TSan changes (r267678) which factor out parts of ThreadState into a Processor structure broke worker threads on OS X. This fixes it by properly calling ProcCreate for GCD worker threads and by replacing some CHECKs with RAW_CHECK in early process initialization. CHECK() in TSan calls the allocator, which requires a valid Processor. llvm-svn: 267864
* [sanitizers] Get the proper symbol version when long double transition is ↵Marcin Koscielnicki2016-04-271-0/+2
| | | | | | | | | | | | | | | | | involved. On linux, some architectures had an ABI transition from 64-bit long double (ie. same as double) to 128-bit long double. On those, glibc symbols involving long doubles come in two versions, and we need to pass the correct one to dlvsym when intercepting them. A few more functions we intercept are also versioned (all printf, scanf, strtold variants), but there's no need to fix these, as the REAL() versions are never called. Differential Revision: http://reviews.llvm.org/D19555 llvm-svn: 267794
* [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: fix windows Go supportDmitry Vyukov2016-04-271-0/+6
| | | | | | Unmap can't unmap arbitrary regions on windows. llvm-svn: 267716
* tsan: make windows shadow mapping a bijectionDmitry Vyukov2016-04-271-1/+4
| | | | | | | | CheckShadowMapping function started catching that mem->shadow->mem mapping is not bijection. Make it bijection. llvm-svn: 267713
* tsan: fix build Dmitry Vyukov2016-04-271-0/+1
| | | | | error: implicit declaration of function 'abort' is invalid in C99 llvm-svn: 267710
* tsan: change tsan/Go interface for obtaining the current ProcessorDmitry Vyukov2016-04-2711-69/+82
| | | | | | | | | | | | | | | Current interface assumes that Go calls ProcWire/ProcUnwire to establish the association between thread and proc. With the wisdom of hindsight, this interface does not work very well. I had to sprinkle Go scheduler with wire/unwire calls, and any mistake leads to hard to debug crashes. This is not something one wants to maintian. Fortunately, there is a simpler solution. We can ask Go runtime as to what is the current Processor, and that question is very easy to answer on Go side. Switch to such interface. llvm-svn: 267703
* tsan: fix windows buildDmitry Vyukov2016-04-271-1/+1
| | | | llvm-svn: 267681
* tsan: add missing fileDmitry Vyukov2016-04-271-0/+61
| | | | llvm-svn: 267680
* tsan: fix compiler warningDmitry Vyukov2016-04-271-2/+1
| | | | | | | | | tsan_debugging.cc: In function ‘void* __tsan_get_current_report()’: tsan_debugging.cc:61:18: warning: cast from type ‘const __tsan::ReportDesc*’ to type ‘void*’ casts away qualifiers [-Wcast-qual] return (void *)rep; llvm-svn: 267679
* tsan: split thread into logical and physical stateDmitry Vyukov2016-04-2717-96/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [sanitizers] [NFC] Add defines for the various PowerPC ABIs.Marcin Koscielnicki2016-04-261-4/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D19542 llvm-svn: 267586
* [sanitizer] rename MmapNoAccess to MmapFixedNoAccess; NFCKostya Serebryany2016-04-221-1/+1
| | | | llvm-svn: 267253
* [tsan] Rename ReportThread->pid to ReportThread->os_idKuba Brecka2016-04-215-6/+6
| | | | | | | | 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
* Revert "[sanitizer] [SystemZ] Abort if the kernel might be vulnerable to ↵Marcin Koscielnicki2016-04-151-3/+0
| | | | | | | | CVE-2016-2143." This reverts commit r266297. llvm-svn: 266470
* [sanitizer] [SystemZ] Abort if the kernel might be vulnerable to CVE-2016-2143.Marcin Koscielnicki2016-04-141-0/+3
| | | | | | | | | | | | | | | | | | 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/D18915 llvm-svn: 266297
* [tsan] Fix size reporting for OS X zone allocator with 0-sized allocationsKuba Brecka2016-04-141-1/+2
| | | | | | | | The custom zone implementation for OS X must not return 0 (even for 0-sized allocations). Returning 0 indicates that the pointer doesn't belong to the zone. This can break existing applications. The underlaying allocator allocates 1 byte for 0-sized allocations anyway, so returning 1 in this case is okay. Differential Revision: http://reviews.llvm.org/D19100 llvm-svn: 266283
* [tsan] Fix a crash with dispatch_source_set_cancel_handler(NULL) on OS XKuba Brecka2016-04-121-0/+12
| | | | | | | | We need to handle the case when handler is NULL in dispatch_source_set_cancel_handler and similar interceptors. Differential Revision: http://reviews.llvm.org/D18968 llvm-svn: 266080
* [tsan] Add support for OS X OSAtomic* functionsKuba Brecka2016-04-071-0/+140
| | | | | | | | OS X provides atomic functions in libkern/OSAtomic.h. These provide atomic guarantees and they have alternatives which have barrier semantics. This patch adds proper TSan support for the functions from libkern/OSAtomic.h. Differential Revision: http://reviews.llvm.org/D18500 llvm-svn: 265665
* [tsan] Add TSan __tsan_atomic* functions to tsan_interface.hKuba Brecka2016-04-072-24/+236
| | | | | | | | To avoid using the public header (tsan_interface_atomic.h), which has different data types, let's add all the __tsan_atomic* functions to tsan_interface.h. Differential Revision: http://reviews.llvm.org/D18543 llvm-svn: 265663
* [tsan] Add interceptors for dispatch_applyKuba Brecka2016-04-071-0/+34
| | | | | | | | Adding an interceptor with two more release+acquire pairs to avoid false positives with dispatch_apply. Differential Revision: http://reviews.llvm.org/D18722 llvm-svn: 265662
* [tsan] Add XPC support (OS X)Kuba Brecka2016-04-071-0/+47
| | | | | | | | XPC APIs have async callbacks, and we need some more happen-before edges to avoid false positives. This patch add them, plus a test case (sorry for the long boilerplate code, but XPC just needs all that). Differential Revision: http://reviews.llvm.org/D18493 llvm-svn: 265661
* [tsan] Add support for dispatch event sourcesKuba Brecka2016-04-071-0/+72
| | | | | | | | GCD has APIs for event sources, we need some more release-acquire pairs to avoid false positives in TSan. Differential Revision: http://reviews.llvm.org/D18515 llvm-svn: 265660
* [tsan] Fix synchronization in dispatch_syncKuba Brecka2016-04-071-24/+62
| | | | | | | | In the interceptor for dispatch_sync, we're currently missing synchronization between the callback and the code *after* the call to dispatch_sync. This patch fixes this by adding an extra release+acquire pair to dispatch_sync() and similar APIs. Added a testcase. Differential Revision: http://reviews.llvm.org/D18502 llvm-svn: 265659
* [tsan] Fix freebsd build.Yabin Cui2016-04-051-1/+3
| | | | | | | | | | | | | | Summary: Freebsd doesn't have <sys/personality.h>, so call personality() only in SANITIZER_LINUX. Reviewers: llvm-commits, dvyukov, zatrazz, rengolin, beanz Subscribers: beanz, emaste Differential Revision: http://reviews.llvm.org/D18785 llvm-svn: 265378
* [tsan] Disable randomized address space on aarch64 linux.Yabin Cui2016-04-041-0/+15
| | | | | | | | | | | | | | | | | Summary: After patch https://lkml.org/lkml/2015/12/21/340 is introduced in linux kernel, the random gap between stack and heap is increased from 128M to 36G on 39-bit aarch64. And it is almost impossible to cover this big range. So we need to disable randomized virtual space on aarch64 linux. Reviewers: llvm-commits, zatrazz, dvyukov, rengolin Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines Differential Revision: http://reviews.llvm.org/D18526 llvm-svn: 265366
* tsan: fix ignore handling in signal handlersDmitry Vyukov2016-04-041-0/+3
| | | | | | | | | | | We've reset thr->ignore_reads_and_writes, but forget to do thr->fast_state.ClearIgnoreBit(). So ignores were not effective reset and fast_state.ignore_bit was corrupted if signal handler itself uses ignores. Properly reset/restore fast_state.ignore_bit around signal handlers. llvm-svn: 265288
* [tsan] Fix a crash when exiting the main thread (e.g. dispatch_main)Kuba Brecka2016-03-281-1/+5
| | | | | | | | This patch fixes the custom ThreadState destruction on OS X to avoid crashing when dispatch_main calls pthread_exit which quits the main thread. Differential Revision: http://reviews.llvm.org/D18496 llvm-svn: 264627
* [sanitizer] Add memset, memmove, and memcpy to the common interceptorsDerek Bruening2016-03-251-35/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, sanitizer_common_interceptors.inc has an implicit, undocumented assumption that the sanitizer including it has previously declared interceptors for memset and memmove. Since the memset, memmove, and memcpy routines require interception by many sanitizers, we add them to the set of common interceptions, both to address the undocumented assumption and to speed future tool development. They are intercepted under a new flag intercept_intrin. The tsan interceptors are removed in favor of the new common versions. The asan and msan interceptors for these are more complex (they incur extra interception steps and their function bodies are exposed to the compiler) so they opt out of the common versions and keep their own. Reviewers: vitalybuka Subscribers: zhaoqin, llvm-commits, kcc Differential Revision: http://reviews.llvm.org/D18465 llvm-svn: 264451
* [tsan] Fix fork() and fork-based tests for OS XKuba Brecka2016-03-241-1/+7
| | | | | | | | On OS X, fork() under TSan asserts (in debug builds only) because REAL(fork) calls some intercepted functions, which check that no internal locks are held via CheckNoLocks(). But the wrapper of fork intentionally holds some locks. This patch fixes that by using ScopedIgnoreInterceptors during the call to REAL(fork). After that, all the fork-based tests seem to pass on OS X, so let's just remove all the UNSUPPORTED: darwin annotations we have. Differential Revision: http://reviews.llvm.org/D18409 llvm-svn: 264261
* Revert "[tsan] Disable randomized address space on linux aarch64."Renato Golin2016-03-231-15/+0
| | | | | | | | This reverts commits r264068 and r264079, and they were breaking the build and weren't reverted in time, nor they exhibited expected behaviour from the reviewers. There is more to discuss than just a test fix. llvm-svn: 264150
* [tsan] Fix check-tsan build by using CHECK_NE.Yabin Cui2016-03-221-1/+1
| | | | | | | | | | Reviewers: llvm-commits, srhines, dvyukov Subscribers: srhines Differential Revision: http://reviews.llvm.org/D18361 llvm-svn: 264079
* [tsan] Disable randomized address space on linux aarch64.Yabin Cui2016-03-221-0/+15
| | | | | | | | | | | | | | | | | Summary: After patch https://lkml.org/lkml/2015/12/21/340 is introduced in linux kernel, the random gap between stack and heap is increased from 128M to 36G on 39-bit aarch64. And it is almost impossible to cover this big range. So I think we need to disable randomized virtual space on aarch64 linux. Reviewers: kcc, llvm-commits, eugenis, zatrazz, dvyukov, rengolin Subscribers: rengolin, aemerson, tberghammer, danalbert, srhines, enh Differential Revision: http://reviews.llvm.org/D18003 llvm-svn: 264068
* [sanitizer] Add strchr* to the common interceptorsEvgeniy Stepanov2016-03-211-28/+0
| | | | | | | | | | | | | | | | Adds strchr, strchrnul, and strrchr to the common interceptors, under a new common flag intercept_strchr. Removes the now-duplicate strchr interceptor from asan and all 3 interceptors from tsan. Previously, asan did not intercept strchrnul, but does now; previously, msan did not intercept strchr, strchrnul, or strrchr, but does now. http://reviews.llvm.org/D18329 Patch by Derek Bruening! llvm-svn: 263992
* [tsan] Add some NULL pointer checks into the debugging APIKuba Brecka2016-03-211-5/+5
| | | | | | | | `__tsan_get_report_thread` and others can crash if a stack trace is missing, let's add the missing checks. Differential Revision: http://reviews.llvm.org/D18306 llvm-svn: 263939
OpenPOWER on IntegriCloud