summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/tsan
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* [tsan] Bump stack frame size limit.Evgeniy Stepanov2016-09-011-1/+1
| | | | llvm-svn: 280411
* [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
* [CMake] Connect Compiler-RT targets to LLVM Runtimes directoryChris Bieneman2016-08-261-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch builds on LLVM r279776. In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth. The three steps I abstract are: (1) Add a top-level target (i.e asan, msan, ...) (2) Set the target properties for sorting files in IDE generators (3) Make the compiler-rt target depend on the top-level target The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name. The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings. With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is: > cmake [...] > ninja runtimes-configure > ninja asan The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build. Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats). llvm-svn: 279863
* [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
* Revert "[CMake] Fix ASM building in llvm/runtimes"Jonas Hahnfeld2016-08-191-0/+19
| | | | | | This reverts the TSAN parts of commit r279215. llvm-svn: 279218
* [CMake] Fix ASM building in llvm/runtimesJonas Hahnfeld2016-08-191-19/+0
| | | | | | | | | | When compiler-rt's CMake is not directly invoked, it will currently not call project() and thus ASM will not be enabled. We also don't need to put the .S files through the C compiler then. Differential Revision: https://reviews.llvm.org/D23656 llvm-svn: 279215
* [TSan][MIPS] Implements setjmp assembly for MIPS64Sagar Thakur2016-08-163-0/+221
| | | | | | | 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
* Follow-up for r277458: Update the tsan_mman_test.cc unit test.Kuba Brecka2016-08-021-4/+4
| | | | llvm-svn: 277463
* [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
* [compiler-rt] Fix VisualStudio virtual folders layoutEtienne Bergeron2016-07-111-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
* [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
* tsan: don't create sync objects on acquireDmitry Vyukov2016-06-275-14/+16
| | | | | | | Creating sync objects on acquire is pointless: acquire of a just created sync object if a no-op. llvm-svn: 273862
* [tsan] Intercept libcxx __release_shared to avoid false positive with ↵Kuba Brecka2016-06-262-0/+48
| | | | | | | | | | weak_ptrs and destructors in C++ There is a "well-known" TSan false positive when using C++ weak_ptr/shared_ptr and code in destructors, e.g. described at <https://llvm.org/bugs/show_bug.cgi?id=22324>. The "standard" solution is to build and use a TSan-instrumented version of libcxx, which is not trivial for end-users. This patch tries a different approach (on OS X): It adds an interceptor for the specific function in libc++.dylib, which implements the atomic operation that needs to be visible to TSan. Differential Revision: http://reviews.llvm.org/D21609 llvm-svn: 273806
* [msan] Intercept send/sendto/sendmsg.Evgeniy Stepanov2016-06-171-23/+0
| | | | | | send/sendmsg moved from tsan to sanitizer_common; sendto is new. llvm-svn: 272980
* [sanitizers] introduce yet another API function: ↵Kostya Serebryany2016-06-161-0/+2
| | | | | | __sanitizer_install_malloc_and_free_hooks llvm-svn: 272943
* tsan: intercept epoll_pwaitDmitry Vyukov2016-06-151-38/+36
| | | | llvm-svn: 272779
* [tsan] Switch to InternalAlloc everywhere __libc_malloc is currently usedKuba Brecka2016-06-065-65/+29
| | | | | | | | | | This patch replaces all uses of __libc_malloc and friends with the internal allocator. It seems that the only reason why we have calls to __libc_malloc in the first place was the lack of the internal allocator at the time. Using the internal allocator will also make sure that the system allocator is never used (this is the same behavior as ASan), and we don’t have to worry about working with unknown pointers coming from the system allocator. Differential Revision: http://reviews.llvm.org/D21025 llvm-svn: 271916
* [tsan] On OS X, optimize main thread’s ThreadState accessesKuba Brecka2016-06-061-7/+5
| | | | | | | | This is a very simple optimization that gets about 10% speedup for certain programs. We’re currently storing the pointer to the main thread’s ThreadState, but we can store the state directly in a static variable, which avoid the load acquire. Differential Revision: http://reviews.llvm.org/D20910 llvm-svn: 271906
* [tsan] On OS X, build Go runtime with -mmacosx-version-minKuba Brecka2016-06-051-2/+2
| | | | | | | | We're not building the Go runtime with -mmacosx-version-min, which means it'll have a minimum deployment target set to the system you're building on. Let's make the code compile (and link) with -mmacosx-version-min=10.7. Differential Revision: http://reviews.llvm.org/D20670 llvm-svn: 271833
* tsan: rely on AnnotateRWLockCreateStatic to detect linker-initialized mutexesDmitry Vyukov2016-06-034-70/+15
| | | | | | | | | The new annotation was added a while ago, but was not actually used. Use the annotation to detect linker-initialized mutexes instead of the broken IsGlobalVar which has both false positives and false negatives. Remove IsGlobalVar mess. llvm-svn: 271663
* tsan: clean up dynamic TLS memory between reuseDmitry Vyukov2016-06-022-12/+24
| | | | | | | | | | | | | Currently the added test produces false race reports with glibc 2.19, because DLTS memory is reused by pthread under the hood. Use the DTLS machinery to intercept new DTLS ranges. __tls_get_addr known to cause issues for tsan in the past, so write the interceptor more carefully. Reviewed in http://reviews.llvm.org/D20927 llvm-svn: 271568
* [sanitizer] Move termination functions in their own fileKostya Serebryany2016-05-272-1/+2
| | | | | | | | | | | | | | | Summary: As suggested by kcc@ in http://reviews.llvm.org/D20084#441418, move the CheckFailed and Die functions, and their associated callback functionalities in their own separate file. I expended the build rules to include a new rule that would not include those termination functions, so that another project can define their own. The tests check-{a,t,m,ub,l,e,df}san are all passing. Reviewers: llvm-commits, kcc Subscribers: kubabrecka Differential Revision: http://reviews.llvm.org/D20742 llvm-svn: 271055
* Init tsan with .preinit_array sectionVitaly Buka2016-05-262-5/+33
| | | | | | | | | | | | Summary: Some libraries, like OpenSSL, runs code from .init section. Reviewers: kcc, eugenis Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20646 llvm-svn: 270873
* Revert "[sanitizer] Move *fstat to the common interceptors"Benjamin Kramer2016-05-191-0/+54
| | | | | | | This reverts commit r269981. Breaks msan tests on linux http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24019/steps/test%20standalone%20compiler-rt/logs/stdio llvm-svn: 270076
* [tsan] Add support for GCD's dispatch_after and dispatch_after_fKuba Brecka2016-05-191-0/+23
| | | | | | | | We're missing interceptors for dispatch_after and dispatch_after_f. Let's add them to avoid false positives. Added a test case. Differential Revision: http://reviews.llvm.org/D20426 llvm-svn: 270071
* [sanitizer] Move *fstat to the common interceptorsMike Aizatsky2016-05-181-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. Resubmit of http://reviews.llvm.org/D20318 with ios build fixes. Reviewers: eugenis, vitalybuka, aizatsky Subscribers: zaks.anna, kcc, bruening, kubabrecka, srhines, danalbert, tberghammer Differential Revision: http://reviews.llvm.org/D20350 llvm-svn: 269981
* [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
OpenPOWER on IntegriCloud