summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/tsan/rtl
Commit message (Collapse)AuthorAgeFilesLines
...
* [sanitizer] Add a 'print_module_map' flag which prints modules with UUIDs on ↵Kuba Mracek2017-01-062-0/+4
| | | | | | | | | | 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
* [tsan] Implement __tsan_get_alloc_stack and __tsan_locate_address to query ↵Kuba Mracek2016-12-193-0/+89
| | | | | | | | | | pointer types and allocation stacks of heap pointers In ASan, we have __asan_locate_address and __asan_get_alloc_stack, which is used in LLDB/Xcode to show the allocation backtrace for a heap memory object. This patch implements the same for TSan. Differential Revision: https://reviews.llvm.org/D27656 llvm-svn: 290119
* [tsan] Add interceptor for libcxx __shared_count::__release_shared()Kuba Mracek2016-12-151-3/+19
| | | | | | | | We already have an interceptor for __shared_weak_count::__release_shared, this patch handles __shared_count::__release_shared in the same way. This should get rid of TSan false positives when using std::future. Differential Revision: https://reviews.llvm.org/D27797 llvm-svn: 289831
* tsan: allow Java VM iterate over allocated objectsDmitry Vyukov2016-12-142-0/+21
| | | | | | | | | | | | Objects may move during the garbage collection, and JVM needs to notify ThreadAnalyzer about that. The new function __tsan_java_find eliminates the need to maintain these objects both in ThreadAnalyzer and JVM. Author: Alexander Smundak (asmundak) Reviewed in https://reviews.llvm.org/D27720 llvm-svn: 289682
* Release memory to OS only when the requested range covers the entire pageEvgeniy Stepanov2016-11-304-6/+6
| | | | | | | | | | | | | | | | | 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
* Return memory to OS right after free (not in the async thread).Evgeniy Stepanov2016-11-291-1/+3
| | | | | | | | | | | | | | | | | | Summary: In order to avoid starting a separate thread to return unused memory to the system (the thread interferes with process startup on Android, Zygota waits for all threads to exit before fork, but this thread never exits), try to return it right after free. Reviewers: eugenis Subscribers: cryptoad, filcab, danalbert, kubabrecka, llvm-commits Patch by Aleksey Shlyapnikov. Differential Revision: https://reviews.llvm.org/D27003 llvm-svn: 288091
* [tsan] Add support for GCD dispatch_suspend and dispatch_resumeKuba Mracek2016-11-241-0/+9
| | | | | | | | GCD queues can be suspended and resumed with dispatch_suspend and dispatch_resume. We need to add synchronization between the call to dispatch_resume and any subsequent executions of blocks in the queue that was resumed. We already have an Acquire(q) before the block executes, so this patch just adds the Release(q) in an interceptor of dispatch_resume. Differential Revision: https://reviews.llvm.org/D27112 llvm-svn: 287902
* 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] Expose __tsan_ignore_thread_begin and __tsan_ignore_thread_end in ↵Anna Zaks2016-11-112-0/+11
| | | | | | | | | | TSan interface This patch is needed to implement the function attribute that disable TSan checking at run time. Differential Revision: https://reviews.llvm.org/D25859 llvm-svn: 286658
* tsan: more precise handling of atomic storesDmitry Vyukov2016-11-081-1/+1
| | | | | | | | | Atomic stores terminate release sequences on the atomic variable, and must use ReleaseStore primitive instead of Release. This was broken in r192355 during a refactoring. Restore correct behavior and add a test. llvm-svn: 286211
* [tsan] Implement WriteMemoryProfile for DarwinKuba Brecka2016-10-312-7/+71
| | | | | | | | TSan’s memory usage profiling currently doesn’t work on Darwin. This patch implements measuring the amount of resident and dirty memory for each memory region. I also removed the GetShadowMemoryConsumption function, which seems to be unused. Differential Revision: https://reviews.llvm.org/D25973 llvm-svn: 285630
* [tsan] Add support for GCD target queuesKuba Brecka2016-10-311-18/+48
| | | | | | | | | | GCD (libdispatch) has a concept of “target queues”: Each queue has either an implicit or explicit target queue, where the task is handed over to when it’s time to execute it. For example, a concurrent queue can have a serial target queue (effectively making the first queue serial), or multiple queues can have the same serial target queue (which means tasks in all the queues are mutually excluded). Thus we need to acquire-release semantics on the full “chain” of target queues. This patch changes the way we Acquire() and Release() when executing tasks in queues. Now we’ll walk the chain of target queues and synchronize on each queue that is serial (or when dealing with a barrier block). This should avoid false positives when using dispatch_set_target_queue(). Differential Revision: https://reviews.llvm.org/D25835 llvm-svn: 285613
* 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-2821-122/+113
| | | | | | | | | | | | | | | | | | | | | | 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 windows meta mappingDmitry Vyukov2016-10-281-0/+5
| | | | | | | | | Currently windows fails on startup with: CHECK failed: gotsan.cc:3077 "(((m - prev_m) / kMetaShadowSize)) == (((p - prev) / kMetaShadowCell))" (0x3ffffffeffffff7e, 0x6ffffff7e) Make MemToMeta do the same MemToShadow does on windows: add offset instead of or'ing it. llvm-svn: 285420
* tsan: fix code formattingDmitry Vyukov2016-10-281-1/+1
| | | | llvm-svn: 285418
* Don't use internal symbolizer if we are in process of reporting Out-of-Memory.Vitaly Buka2016-09-291-2/+2
| | | | | | Reviewed by eugenis offline, as reviews.llvm.org is down. llvm-svn: 282805
* 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-262-19/+31
| | | | | | | | | | | | | | | | | | | 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: remove kMidShadowOff mapping parameterDmitry Vyukov2016-09-261-6/+2
| | | | | | | kMidShadowOff is trivially computable from other parameters. Remove it. llvm-svn: 282404
* tsan: simplify meta mappingDmitry Vyukov2016-09-261-3/+2
| | | | | | | | | | | Don't xor user address with kAppMemXor in meta mapping. The only purpose of kAppMemXor is to raise shadow for ~0 user addresses, so that they don't map to ~0 (which would cause overlap between user memory and shadow). For meta mapping we explicitly add kMetaShadowBeg offset, so we don't need to additionally raise meta shadow. llvm-svn: 282403
* tsan: fix bug introduced in 282152Dmitry Vyukov2016-09-221-4/+4
| | | | | | | | In ShadowToMem we call MemToShadow potentially for incorrect addresses. So DCHECK(IsAppMem(p)) can fire in debug mode. Fix this by swapping range and MemToShadow checks. llvm-svn: 282157
* tsan: support pie binaries on newer kernelsDmitry Vyukov2016-09-221-22/+35
| | | | | | | | | | | | | 4.1+ Linux kernels map pie binaries at 0x55: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90 Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503). Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb). This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb. This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping. llvm-svn: 282152
* 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
* 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
* [compiler-rt] Do not introduce __sanitizer namespace globallyAnna Zaks2016-09-151-0/+1
| | | | | | | | | | | | The definitions in sanitizer_common may conflict with definitions from system headers because: The runtime includes the system headers after the project headers (as per LLVM coding guidelines). lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry. Differential Revision: https://reviews.llvm.org/D21947 llvm-svn: 281657
* [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
* [tsan] Support C++11 call_once in TSan on DarwinKuba Brecka2016-09-081-0/+27
| | | | | | | | This patch adds a wrapper for call_once, which uses an already-compiled helper __call_once with an atomic release which is invisible to TSan. To avoid false positives, the interceptor performs an explicit atomic release in the callback wrapper. Differential Revision: https://reviews.llvm.org/D24188 llvm-svn: 280920
* [asan] first attempt at releasing free-d memory back to the system using ↵Kostya Serebryany2016-08-264-5/+5
| | | | | | madvise. Requires quite some tuning. llvm-svn: 279887
* [sanitizer] enable random shuffling the memory chunks inside the allocator, ↵Kostya Serebryany2016-08-261-0/+1
| | | | | | under a flag. Set this flag for the scudo allocator, add a test. llvm-svn: 279793
* [sanitizer] change SizeClassAllocator64 to accept just one template ↵Kostya Serebryany2016-08-251-3/+8
| | | | | | parameter instead of 5. First, this will make the mangled names shorter. Second, this will make adding more parameters simpler. llvm-svn: 279771
* [TSan][MIPS] Changes mips memory layout to support pie with address space ↵Sagar Thakur2016-08-231-8/+13
| | | | | | | | | randomization. Reviewed by dvyukov Differential: D23644 llvm-svn: 279505
* [TSan][MIPS] Implements setjmp assembly for MIPS64Sagar Thakur2016-08-162-0/+216
| | | | | | | Reviewed by dvyukov Differential: https://reviews.llvm.org/D23494 llvm-svn: 278775
* tsan: Remove __pointer_chk_guard@GLIBC_PRIVATE requirement for AArch64Adhemerval Zanella2016-08-102-12/+71
| | | | | | | | | | | | | | | | | | | | | Current AArch64 {sig}{set,long}jmp interposing requires accessing glibc private __pointer_chk_guard to get process xor mask to demangled the internal {sig}jmp_buf function pointers. It causes some packing issues, as described in gcc PR#71042 [1], and is is not a godd practice to rely on a private glibc namespace (since ABI is not meant to be stable). This patch fixes it by changing how libtsan obtains the guarded pointer value: at initialization a specific routine issues a setjmp call and using the mangled function pointer and the original value derive the random guarded pointer. Checked on aarch64 39-bit VMA. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042 llvm-svn: 278292
* [tsan] Fix the behavior of OSAtomicTestAndClearKuba Brecka2016-08-021-10/+9
| | | | | | | | The system implementation of OSAtomicTestAndClear returns the original bit, but the TSan interceptor has a bug which always returns zero from the function. This patch fixes this and adds a test. Differential Revision: https://reviews.llvm.org/D23061 llvm-svn: 277461
* [tsan] Fix behavior of realloc(nullptr, 0) on DarwinKuba Brecka2016-08-021-11/+7
| | | | | | | | On Darwin, there are some apps that rely on realloc(nullptr, 0) returning a valid pointer. TSan currently returns nullptr in this case, let's fix it to avoid breaking binary compatibility. Differential Revision: https://reviews.llvm.org/D22800 llvm-svn: 277458
* tsan: Enable 48-bit VMA support on aarch64Adhemerval Zanella2016-07-294-42/+85
| | | | | | | | | | | | | | | | | | 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
* tsan: don't deliver signals when they are blockedDmitry Vyukov2016-07-271-9/+32
| | | | | | | | | | When we delay signals we can deliver them when the signal is blocked. This can be surprising to the program. Intercept signal blocking functions merely to process pending signals. As the result, at worst we will delay a signal till return from the signal blocking function. llvm-svn: 276876
* tsan: fix leak of shadow stacksDmitry Vyukov2016-07-201-0/+6
| | | | llvm-svn: 276103
* [tsan] Add support for GCD IO channels on DarwinKuba Brecka2016-07-111-9/+184
| | | | | | | | This patch adds interceptors for dispatch_io_*, dispatch_read and dispatch_write functions. This avoids false positives when using GCD IO. Adding several test cases. Differential Revision: http://reviews.llvm.org/D21889 llvm-svn: 275071
* [tsan] Avoid false positives with GCD data callbacksKuba Brecka2016-07-071-0/+26
| | | | | | | | This patch adds synchronization between the creation of the GCD data object and destructor’s execution. It’s far from perfect, because ideally we’d want to synchronize the destruction of the last reference (via dispatch_release) and the destructor’s execution, but intercepting objc_release is problematic. Differential Revision: http://reviews.llvm.org/D21990 llvm-svn: 274749
* [tsan] Fix false positives with GCD dispatch_source_*Kuba Brecka2016-07-061-24/+44
| | | | | | | | We already have interceptors for dispatch_source API (e.g. dispatch_source_set_event_handler), but they currently only handle submission synchronization. We also need to synchronize based on the target queue (serial, concurrent), in other words, we need to use dispatch_callback_wrap. This patch implements that. Differential Revision: http://reviews.llvm.org/D21999 llvm-svn: 274619
* [tsan] Synchronize leaving a GCD group with notificationsKuba Brecka2016-07-051-9/+17
| | | | | | | | In the patch that introduced support for GCD barrier blocks, I removed releasing a group when leaving it (in dispatch_group_leave). However, this is necessary to synchronize leaving a group and a notification callback (dispatch_group_notify). Adding this back, simplifying dispatch_group_notify_f and adding a test case. Differential Revision: http://reviews.llvm.org/D21927 llvm-svn: 274549
* [tsan] dispatch_once interceptor will cause a crash/deadlock when the ↵Kuba Brecka2016-07-051-2/+2
| | | | | | | | | | original dispatch_once is used Because we use SCOPED_TSAN_INTERCEPTOR in the dispatch_once interceptor, the original dispatch_once can also be sometimes called (when ignores are enabled or when thr->is_inited is false). However the original dispatch_once function doesn’t expect to find “2” in the storage and it will spin forever (but we use “2” to indicate that the initialization is already done, so no waiting is necessary). This patch makes sure we never call the original dispatch_once. Differential Revision: http://reviews.llvm.org/D21976 llvm-svn: 274548
* [tsan] Stop extending the block’s lifetime in dispatch_group_asyncKuba Brecka2016-06-291-1/+3
| | | | | | | | The dispatch_group_async interceptor actually extends the lifetime of the executed block. This means the destructor of the block (and captured variables) is called *after* dispatch_group_leave, which changes the semantics of dispatch_group_async. This patch fixes that. Differential Revision: http://reviews.llvm.org/D21816 llvm-svn: 274117
* [tsan] Add HB edges for GCD barrier blocksKuba Brecka2016-06-271-48/+35
| | | | | | | | Adding support for GCD barrier blocks in concurrent queues. This uses two sync object in the same way as read-write locks do. This also simplifies the use of dispatch groups (the notifications act as barrier blocks). Differential Revision: http://reviews.llvm.org/D21604 llvm-svn: 273893
* [tsan] Treat non-barrier OSAtomic* functions as barriers to avoid false ↵Kuba Brecka2016-06-271-15/+24
| | | | | | | | | | positives The non-barrier versions of OSAtomic* functions are semantically mo_relaxed, but the two variants (e.g. OSAtomicAdd32 and OSAtomicAdd32Barrier) are actually aliases of each other, and we cannot have different interceptors for them, because they're actually the same function. Thus, we have to stay conservative and treat the non-barrier versions as mo_acq_rel. Differential Revision: http://reviews.llvm.org/D21733 llvm-svn: 273890
OpenPOWER on IntegriCloud