| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[compiler-rt][NFC] Inclusive language: remove use of sanity check/test from compiler-rt/lib/tsan [NFC] As part of using inclusive language within the llvm project, this patch rewords comments to remove sanity check and sanity test. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D124390 | 4 年前 | |
[compiler-rt][tsan] Make fiber support in thread sanitizer dynamic linkable This patch will allow dynamic libraries to call into the fiber support functions introduced in https://reviews.llvm.org/D54889 Differential Revision: https://reviews.llvm.org/D74487 | 6 年前 | |
tsan: remove unused ReportMutex::destroyed Depends on D113980. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D113981 | 4 年前 | |
Init project. | 11 个月前 | |
tsan: optimize DenseSlabAlloc If lots of threads do lots of malloc/free and they overflow per-pthread DenseSlabAlloc cache, it causes lots of contention: 31.97% race.old race.old [.] __sanitizer::StaticSpinMutex::LockSlow 17.61% race.old race.old [.] __tsan_read4 10.77% race.old race.old [.] __tsan::SlotLock Optimize DenseSlabAlloc to use a lock-free stack of batches of nodes. This way we don't take any locks in steady state at all and do only 1 push/pop per Refill/Drain. Effect on the added benchmark: $ TIME="%e %U %S %M" time ./test.old 36 5 2000000 34.51 978.22 175.67 5833592 32.53 891.73 167.03 5790036 36.17 1005.54 201.24 5802828 36.94 1004.76 226.58 5803188 $ TIME="%e %U %S %M" time ./test.new 36 5 2000000 26.44 720.99 13.45 5750704 25.92 721.98 13.58 5767764 26.33 725.15 13.41 5777936 25.93 713.49 13.41 5791796 Reviewed By: melver Differential Revision: https://reviews.llvm.org/D130002 | 3 年前 | |
[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816) Performed a global search/replace as in title against LLVM sources Differential Revision: https://reviews.llvm.org/D126263 | 4 年前 | |
Init project. | 11 个月前 | |
tsan: avoid false positives related to epoll An application can use the mere fact of epoll_wait returning an fd as synchronization with the write on the fd that triggered the notification. This pattern come up in an internal networking server (b/229276331). If an fd is added to epoll, setup a link from the fd to the epoll fd and use it for synchronization as well. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D124518 | 4 年前 | |
tsan: avoid false positives related to epoll An application can use the mere fact of epoll_wait returning an fd as synchronization with the write on the fd that triggered the notification. This pattern come up in an internal networking server (b/229276331). If an fd is added to epoll, setup a link from the fd to the epoll fd and use it for synchronization as well. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D124518 | 4 年前 | |
[compiler-rt][NFC] Inclusive language: remove use of sanity check/test from compiler-rt/lib/tsan [NFC] As part of using inclusive language within the llvm project, this patch rewords comments to remove sanity check and sanity test. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D124390 | 4 年前 | |
Improve error message when '=' is missing in {ASAN,...}_OPTIONS. 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 | 6 年前 | |
tsan: remove tracking of racy addresses We used to deduplicate based on the race address to prevent lots of repeated reports about the same race. But now we clear the shadow for the racy address in DoReportRace: // This prevents trapping on this address in future. for (uptr i = 0; i < kShadowCnt; i++) StoreShadow(&shadow_mem[i], i == 0 ? Shadow::kRodata : Shadow::kEmpty); It should have the same effect of not reporting duplicates (and actually better because it's automatically reset when the memory is reallocated). So drop the address deduplication code. Both simpler and faster. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D130240 | 3 年前 | |
tsan: minor IgnoreSet refactoring 1. Move kMaxSize declaration to private section. 2. Inline Reset, it's trivial and called semi-frequently. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107215 | 4 年前 | |
tsan: minor IgnoreSet refactoring 1. Move kMaxSize declaration to private section. 2. Inline Reset, it's trivial and called semi-frequently. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107215 | 4 年前 | |
tsan: add intrusive doubly-linked list Add intrusive doubly-linked list container template, IList. It will be used in the new tsan runtime. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107050 | 4 年前 | |
[TSan] Handle FreeBSD specific indirection of libpthread functions Similar to 60cc1d3218fc for NetBSD, add aliases and interceptors for the following pthread related functions: - pthread_cond_init(3) - pthread_cond_destroy(3) - pthread_cond_signal(3) - pthread_cond_broadcast(3) - pthread_cond_wait(3) - pthread_mutex_init(3) - pthread_mutex_destroy(3) - pthread_mutex_lock(3) - pthread_mutex_trylock(3) - pthread_mutex_unlock(3) - pthread_rwlock_init(3) - pthread_rwlock_destroy(3) - pthread_rwlock_rdlock(3) - pthread_rwlock_tryrdlock(3) - pthread_rwlock_wrlock(3) - pthread_rwlock_trywrlock(3) - pthread_rwlock_unlock(3) - pthread_once(3) - pthread_sigmask(3) In FreeBSD's libc, a number of internal aliases of the pthread functions are invoked, typically with an additional prefixed underscore, e.g. _pthread_cond_init() and so on. ThreadSanitizer needs to intercept these aliases too, otherwise some false positive reports about data races might be produced. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D119034 | 4 年前 | |
[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816) Performed a global search/replace as in title against LLVM sources Differential Revision: https://reviews.llvm.org/D126263 | 4 年前 | |
[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816) Performed a global search/replace as in title against LLVM sources Differential Revision: https://reviews.llvm.org/D126263 | 4 年前 | |
[TSan][Darwin] Handle NULL argument in interceptor Handle NULL address argument in the mach_vm_[de]allocate() interceptors and fix test: Assignment 2 is not valid if we weren't able to re-allocate memory. rdar://67680613 | 5 年前 | |
[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816) Performed a global search/replace as in title against LLVM sources Differential Revision: https://reviews.llvm.org/D126263 | 4 年前 | |
tsan: optimize __tsan_read/write16 These callbacks are used for SSE vector accesses. In some computational programs these accesses dominate. Currently we do 2 uninlined 8-byte accesses to handle them. Inline and optimize them similarly to unaligned accesses. This reduces the vector access benchmark time from 8 to 3 seconds. Depends on D112603. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D114594 | 4 年前 | |
Init project. | 11 个月前 | |
tsan: optimize __tsan_read/write16 These callbacks are used for SSE vector accesses. In some computational programs these accesses dominate. Currently we do 2 uninlined 8-byte accesses to handle them. Inline and optimize them similarly to unaligned accesses. This reduces the vector access benchmark time from 8 to 3 seconds. Depends on D112603. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D114594 | 4 年前 | |
tsan: prevent insertion of memset into BenignRaceImpl Some bots started failing with the following error after changing Alloc to New. Change it back. ThreadSanitizer: CHECK failed: ((locked[i].recursion)) == ((0)) 4 __sanitizer::CheckedMutex::CheckNoLocks() 5 __tsan::ScopedInterceptor::~ScopedInterceptor() 6 memset 7 __tsan::New<__tsan::ExpectRace>() 8 __tsan::AddExpectRace() 9 BenignRaceImpl() Differential Revision: https://reviews.llvm.org/D107212 | 4 年前 | |
Update the file headers across all of the LLVM projects in the monorepo 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 | 7 年前 | |
Init project. | 11 个月前 | |
tsan: new runtime (v3) This change switches tsan to the new runtime which features: - 2x smaller shadow memory (2x of app memory) - faster fully vectorized race detection - small fixed-size vector clocks (512b) - fast vectorized vector clock operations - unlimited number of alive threads/goroutimes Depends on D112602. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D112603 | 4 年前 | |
Remove NOLINTs from compiler-rt llvm-svn: 371687 | 6 年前 | |
[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816) Performed a global search/replace as in title against LLVM sources Differential Revision: https://reviews.llvm.org/D126263 | 4 年前 | |
Remove NOLINTs from compiler-rt llvm-svn: 371687 | 6 年前 | |
[NFC][sanitizer] Consolidate malloc hook invocations | 4 年前 | |
tsan: new runtime (v3) This change switches tsan to the new runtime which features: - 2x smaller shadow memory (2x of app memory) - faster fully vectorized race detection - small fixed-size vector clocks (512b) - fast vectorized vector clock operations - unlimited number of alive threads/goroutimes Depends on D112602. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D112603 | 4 年前 | |
tsan: new runtime (v3) This change switches tsan to the new runtime which features: - 2x smaller shadow memory (2x of app memory) - faster fully vectorized race detection - small fixed-size vector clocks (512b) - fast vectorized vector clock operations - unlimited number of alive threads/goroutimes Depends on D112602. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D112603 | 4 年前 | |
tsan: new runtime (v3) This change switches tsan to the new runtime which features: - 2x smaller shadow memory (2x of app memory) - faster fully vectorized race detection - small fixed-size vector clocks (512b) - fast vectorized vector clock operations - unlimited number of alive threads/goroutimes Depends on D112602. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D112603 | 4 年前 | |
Remove NOLINTs from compiler-rt llvm-svn: 371687 | 6 年前 | |
Init project. | 11 个月前 | |
Init project. | 11 个月前 | |
[Sanitizer][Darwin] Factor out code for GCD worker registration This is a NFC change to factor out GCD worker thread registration via the pthread introspection hook. In a follow-up change we also want to register GCD workers for ASan to make sure threads are registered before we attempt to print reports on them. rdar://93276353 Differential Revision: https://reviews.llvm.org/D126351 | 3 年前 | |
Init project. | 11 个月前 | |
tsan: new runtime (v3) This change switches tsan to the new runtime which features: - 2x smaller shadow memory (2x of app memory) - faster fully vectorized race detection - small fixed-size vector clocks (512b) - fast vectorized vector clock operations - unlimited number of alive threads/goroutimes Depends on D112602. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D112603 | 4 年前 | |
[PPC64, TSAN] Provide setjmp interceptor support for PPC64 This patch provides the assembly support for setjmp/longjmp for use with the thread sanitizer. This is a big more complicated than for aarch64, because sibcalls are only legal under our ABIs if the TOC pointer is unchanged. Since the true setjmp function trashes the TOC pointer, and we have to leave the stack in a correct state, we emulate the setjmp function rather than branching to it. We also need to materialize the TOC for cases where the _setjmp code is called from libc. This is done differently under the ELFv1 and ELFv2 ABIs. llvm-svn: 255059 | 10 年前 | |
compiler-rt: Rename .cc file in lib/tsan/rtl to .cpp Like r367463, but for tsan/rtl. llvm-svn: 367564 | 6 年前 | |
Init project. | 11 个月前 | |
tsan: print signal num in errno spoiling reports For errno spoiling reports we only print the stack where the signal handler is invoked. And the top frame is the signal handler function, which is supposed to give the info for debugging. But in same cases the top frame can be some common thunk, which does not give much info. E.g. for Go/cgo it's always runtime.cgoSigtramp. Print the signal number. This is what we can easily gather and it may give at least some hints regarding the issue. Reviewed By: melver, vitalybuka Differential Revision: https://reviews.llvm.org/D121979 | 4 年前 | |
Init project. | 11 个月前 | |
Init project. | 11 个月前 | |
[TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.6 Cleanup ARM64 assembly after removing unnecessary computation of mangled stack pointer in previous commit. llvm-svn: 366258 | 6 年前 | |
tsan: prevent pathological slowdown for spurious races Prevent the following pathological behavior: Since memory access handling is not synchronized with DoReset, a thread running concurrently with DoReset can leave a bogus shadow value that will be later falsely detected as a race. For such false races RestoreStack will return false and we will not report it. However, consider that a thread leaves a whole lot of such bogus values and these values are later read by a whole lot of threads. This will cause massive amounts of ReportRace calls and lots of serialization. In very pathological cases the resulting slowdown can be >100x. This is very unlikely, but it was presumably observed in practice: https://github.com/google/sanitizers/issues/1552 If this happens, previous access sid+epoch will be the same for all of these false races b/c if the thread will try to increment epoch, it will notice that DoReset has happened and will stop producing bogus shadow values. So, last_spurious_race is used to remember the last sid+epoch for which RestoreStack returned false. Then it is used to filter out races with the same sid+epoch very early and quickly. It is of course possible that multiple threads left multiple bogus shadow values and all of them are read by lots of threads at the same time. In such case last_spurious_race will only be able to deduplicate a few races from one thread, then few from another and so on. An alternative would be to hold an array of such sid+epoch, but we consider such scenario as even less likely. Note: this can lead to some rare false negatives as well: 1. When a legit access with the same sid+epoch participates in a race as the "previous" memory access, it will be wrongly filtered out. 2. When RestoreStack returns false for a legit memory access because it was already evicted from the thread trace, we will still remember it in last_spurious_race. Then if there is another racing memory access from the same thread that happened in the same epoch, but was stored in the next thread trace part (which is still preserved in the thread trace), we will also wrongly filter it out while RestoreStack would actually succeed for that second memory access. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D130269 | 3 年前 | |
tsan: remove hacky call It's unused in the new tsan runtime. Depends on D112603. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D112604 | 4 年前 | |
[TSan][MIPS] Implements setjmp assembly for MIPS64 Reviewed by dvyukov Differential: https://reviews.llvm.org/D23494 llvm-svn: 278775 | 9 年前 | |
tsan: fix false positive during fd close FdClose is a subjet to the same atomicity problem as MemoryRangeFreed (memory state is not "monotoic" wrt race detection). So we need to lock the thread slot in FdClose the same way we do in MemoryRangeFreed. This fixes the modified stress.cpp test. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D121143 | 4 年前 | |
Avoid extended mnemonic 'mfvrsave' in assembly code llvm-svn: 255116 | 10 年前 | |
Init project. | 11 个月前 | |
Init project. | 11 个月前 | |
[compiler-rt] Add NO_EXEC_STACK_DIRECTIVE on s390x Differential Revision: https://reviews.llvm.org/D125454 | 4 年前 | |
Init project. | 11 个月前 | |
tsan: prevent pathological slowdown for spurious races Prevent the following pathological behavior: Since memory access handling is not synchronized with DoReset, a thread running concurrently with DoReset can leave a bogus shadow value that will be later falsely detected as a race. For such false races RestoreStack will return false and we will not report it. However, consider that a thread leaves a whole lot of such bogus values and these values are later read by a whole lot of threads. This will cause massive amounts of ReportRace calls and lots of serialization. In very pathological cases the resulting slowdown can be >100x. This is very unlikely, but it was presumably observed in practice: https://github.com/google/sanitizers/issues/1552 If this happens, previous access sid+epoch will be the same for all of these false races b/c if the thread will try to increment epoch, it will notice that DoReset has happened and will stop producing bogus shadow values. So, last_spurious_race is used to remember the last sid+epoch for which RestoreStack returned false. Then it is used to filter out races with the same sid+epoch very early and quickly. It is of course possible that multiple threads left multiple bogus shadow values and all of them are read by lots of threads at the same time. In such case last_spurious_race will only be able to deduplicate a few races from one thread, then few from another and so on. An alternative would be to hold an array of such sid+epoch, but we consider such scenario as even less likely. Note: this can lead to some rare false negatives as well: 1. When a legit access with the same sid+epoch participates in a race as the "previous" memory access, it will be wrongly filtered out. 2. When RestoreStack returns false for a legit memory access because it was already evicted from the thread trace, we will still remember it in last_spurious_race. Then if there is another racing memory access from the same thread that happened in the same epoch, but was stored in the next thread trace part (which is still preserved in the thread trace), we will also wrongly filter it out while RestoreStack would actually succeed for that second memory access. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D130269 | 3 年前 | |
tsan: introduce New/Alloc/Free helpers We frequenty allocate sizeof(T) memory and call T ctor on that memory (C++ new keyword effectively). Currently it's quite verbose and usually takes 2 lines of code. Add New<T>() helper that does it much more concisely. Rename internal_free to Free that also sets the pointer to nullptr. Shorter and safer. Rename internal_alloc to Alloc, just shorter. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D107085 | 4 年前 | |
Update the file headers across all of the LLVM projects in the monorepo 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 | 7 年前 | |
Remove NOLINTs from compiler-rt llvm-svn: 371687 | 6 年前 | |
Update the file headers across all of the LLVM projects in the monorepo 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 | 7 年前 | |
tsan: introduce New/Alloc/Free helpers We frequenty allocate sizeof(T) memory and call T ctor on that memory (C++ new keyword effectively). Currently it's quite verbose and usually takes 2 lines of code. Add New<T>() helper that does it much more concisely. Rename internal_free to Free that also sets the pointer to nullptr. Shorter and safer. Rename internal_alloc to Alloc, just shorter. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D107085 | 4 年前 | |
Update the file headers across all of the LLVM projects in the monorepo 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 | 7 年前 | |
tsan: new runtime (v3) This change switches tsan to the new runtime which features: - 2x smaller shadow memory (2x of app memory) - faster fully vectorized race detection - small fixed-size vector clocks (512b) - fast vectorized vector clock operations - unlimited number of alive threads/goroutimes Depends on D112602. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D112603 | 4 年前 | |
tsan: remove old vector clocks They are unused in the new tsan runtime. Depends on D112604. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D112605 | 4 年前 | |
tsan: new runtime (v3) This change switches tsan to the new runtime which features: - 2x smaller shadow memory (2x of app memory) - faster fully vectorized race detection - small fixed-size vector clocks (512b) - fast vectorized vector clock operations - unlimited number of alive threads/goroutimes Depends on D112602. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D112603 | 4 年前 | |
[tsan] Complete renaming kMaxSid to kThreadSlotCount This was missing from 5c2b48fdb0a6 | 4 年前 | |
tsan: add new vector clock Add new fixed-size vector clock for the new tsan runtime. For now it's unused. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107167 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 10 年前 | ||
| 6 年前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 9 年前 | ||
| 4 年前 | ||
| 10 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 |