summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/lsan
Commit message (Collapse)AuthorAgeFilesLines
...
* Use pthreads for thread-local lsan allocator cache on darwinFrancis Ricci2017-03-274-38/+49
| | | | | | | | | | | | | | | Summary: This patch allows us to move away from using __thread on darwin, which is requiring for building lsan for darwin on ios version 7 and on iossim i386. Reviewers: kubamracek, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31291 llvm-svn: 298848
* Factor lsan allocator cache accesses into a functionFrancis Ricci2017-03-221-8/+9
| | | | | | | | | | | | | | | | | | Summary: This patch is the first step towards allows us to move away from using __thread for the allocator cache on darwin, which is requiring for building lsan for darwin on ios version 7 and on iossim i386. This will be followed by patches to move the function into OS-specific files. Reviewers: kubamracek, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29994 llvm-svn: 298537
* Revert r298274: "Use pthreads for thread-local lsan allocator cache on darwin"Chandler Carruth2017-03-214-56/+44
| | | | | | | | This fixes a failure currently present on the upstream linux boxes (and reproduces for me as well): http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/1130/steps/64-bit%20check-asan-dynamic/logs/stdio llvm-svn: 298382
* Use pthreads for thread-local lsan allocator cache on darwinFrancis Ricci2017-03-204-44/+56
| | | | | | | | | | | | | | | Summary: This patch allows us to move away from using __thread on darwin, which is requiring for building lsan for darwin on ios version 7 and on iossim i386. Reviewers: kubamracek, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29994 llvm-svn: 298274
* Revert "Use pthreads for thread-local lsan allocator cache on darwin"Francis Ricci2017-03-204-56/+44
| | | | | | | | This is still failing stack-use-after-return on linux-aarch64. This reverts commit 5b350130fc4bf6f70c078a5d97096df98a17a057. llvm-svn: 298246
* Use pthreads for thread-local lsan allocator cache on darwinFrancis Ricci2017-03-194-44/+56
| | | | | | | | | | | | | | | Summary: This patch allows us to move away from using __thread on darwin, which is requiring for building lsan for darwin on ios version 7 and on iossim i386. Reviewers: kubamracek, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29994 llvm-svn: 298214
* Revert "Use pthreads for thread-local lsan allocator cache on darwin"Francis Ricci2017-03-024-56/+44
| | | | | | | | Reverting due to revert of prerequisite patch r296706 This reverts commit 6e1f23078c1acc44295065d28167043c4d31ddd1. llvm-svn: 296720
* Use pthreads for thread-local lsan allocator cache on darwinFrancis Ricci2017-03-014-44/+56
| | | | | | | | | | | | | | | Summary: This patch allows us to move away from using __thread on darwin, which is requiring for building lsan for darwin on ios version 7 and on iossim i386. Reviewers: kubamracek, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29994 llvm-svn: 296707
* Revert "Use pthreads for thread-local lsan allocator cache on darwin"Francis Ricci2017-02-174-56/+44
| | | | | | | | This caused a failure in Linux-x86_64 stack-use-after-return This reverts commit 1f9563141e999016d13ac3fc6a50fde690381e82. llvm-svn: 295449
* Use pthreads for thread-local lsan allocator cache on darwinFrancis Ricci2017-02-174-44/+56
| | | | | | | | | | | | | | | Summary: This patch allows us to move away from using __thread on darwin, which is requiring for building lsan for darwin on ios version 7 and on iossim i386. Reviewers: kubamracek, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29994 llvm-svn: 295413
* Fix build breakage from moving kInvalidTid to lsan_commonFrancis Ricci2017-02-171-0/+1
| | | | llvm-svn: 295409
* Use pthreads to store current thread id on darwinFrancis Ricci2017-02-174-26/+24
| | | | | | | | | | | | | | Summary: __thread is not supported by all darwin versions and architectures, use pthreads instead to allow for building darwin lsan on iossim. Reviewers: kubamracek, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29993 llvm-svn: 295405
* Add cmake build support for lsan on OS XFrancis Ricci2017-02-143-10/+35
| | | | | | | | | | | | | | | | | | | | Summary: Adds a new cmake flag 'COMPILER_RT_ENABLE_LSAN_OSX', which enables lsan compilation and is turned off by default. Patches to fix build errors when this flag is enabled will be uploaded soon. This is part of an effort to port LSan to OS X, but LSan on OS X does not currently work or pass tests currently. Reviewers: kubamracek, kcc, glider, alekseyshl Reviewed By: kubamracek Subscribers: danalbert, srhines, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29783 llvm-svn: 295012
* Use pthreads to manage thread-local storage on darwin for leak sanitizerFrancis Ricci2017-02-134-9/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: __thread is supported on Darwin, but is implemented dynamically via function calls to __tls_get_addr. This causes two issues when combined with leak sanitizer, due to malloc() interception. - The dynamic loader calls malloc during the process of loading the sanitizer dylib, while swapping a placeholder tlv_boostrap function for __tls_get_addr. This will cause tlv_bootstrap to be called in DisabledInThisThread() via the asan allocator. - The first time __tls_get_addr is called, it allocates memory for the thread-local object, during which it calls malloc(). This call will be intercepted, leading to an infinite loop in the asan allocator, in which the allocator calls DisabledInThisThread, which calls tls_get_addr, which calls into the allocator again. Reviewers: kcc, glider, kubamracek Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29786 llvm-svn: 294994
* Disable darwin interception of non-darwin functionsFrancis Ricci2017-02-131-2/+13
| | | | | | | | | | | | Summary: Fixes build issues when compiling lsan for darwin. Reviewers: kubamracek, kcc, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29785 llvm-svn: 294984
* Add lsan function stubs for darwinFrancis Ricci2017-02-132-1/+42
| | | | | | | | | | | | | | | | Summary: This patch provides stubs for all of the lsan platform-specific functions which need to be implemented for darwin. Currently all of these functions are stubs, for the purpose of fixing compilation. Reviewers: kcc, glider, kubamracek Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29784 llvm-svn: 294983
* [tsan] Properly describe GCD worker threads in reportsKuba Mracek2017-02-021-1/+1
| | | | | | | | When dealing with GCD worker threads, TSan currently prints weird things like "created by thread T-1" and "[failed to restore the stack]" in reports. This patch avoids that and instead prints "Thread T3 (...) is a GCD worker thread". Differential Revision: https://reviews.llvm.org/D29103 llvm-svn: 293882
* [lsan] Renable LSan for x86 LinuxMaxim Ostapenko2017-01-313-5/+26
| | | | | | | | | The missed clang part was committed at https://reviews.llvm.org/rL293609 thus we can reenable LSan for x86 Linux. Differential Revision: https://reviews.llvm.org/D28609 llvm-svn: 293610
* Recommit: Stop intercepting some malloc-related functions on FreeBSD andDimitry Andric2017-01-301-14/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | macOS Summary: In https://bugs.freebsd.org/215125 I was notified that some configure scripts attempt to test for the Linux-specific `mallinfo` and `mallopt` functions by compiling and linking small programs which references the functions, and observing whether that results in errors. FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so normally these tests would fail, but when sanitizers are enabled, they incorrectly succeed, because the sanitizers define interceptors for these functions. This also applies to some other malloc-related functions, such as `memalign`, `pvalloc` and `cfree`. Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`, `pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers. Also delete the non-functional `cfree` wrapper for Windows, to fix the test cases on that platform. Reviewers: emaste, kcc, rnk Subscribers: timurrrr, eugenis, hans, joerg, llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D27654 llvm-svn: 293536
* Revert "Stop intercepting some malloc-related functions on FreeBSD and macOS"Evgeniy Stepanov2017-01-271-40/+14
| | | | | | | | This reverts r293337, which breaks tests on Windows: malloc-no-intercept-499eb7.o : error LNK2019: unresolved external symbol _mallinfo referenced in function _main llvm-svn: 293346
* Stop intercepting some malloc-related functions on FreeBSD and macOSDimitry Andric2017-01-271-14/+40
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: In https://bugs.freebsd.org/215125 I was notified that some configure scripts attempt to test for the Linux-specific `mallinfo` and `mallopt` functions by compiling and linking small programs which references the functions, and observing whether that results in errors. FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so normally these tests would fail, but when sanitizers are enabled, they incorrectly succeed, because the sanitizers define interceptors for these functions. This also applies to some other malloc-related functions, such as `memalign`, `pvalloc` and `cfree`. Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`, `pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers. Reviewers: emaste, kcc Subscribers: hans, joerg, llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D27654 llvm-svn: 293337
* Revert "[lsan] Enable LSan for x86 Linux."Evgeniy Stepanov2017-01-233-26/+5
| | | | | | | Breaks tests on i686/Linux due to missing clang driver support: error: unsupported option '-fsanitize=leak' for target 'i386-unknown-linux-gnu' llvm-svn: 292844
* [lsan] Enable LSan for x86 Linux.Maxim Ostapenko2017-01-233-5/+26
| | | | | | | | | | | | | People keep asking LSan to be available on 32 bit targets (e.g. https://github.com/google/sanitizers/issues/403) despite the fact that false negative ratio might be huge (up to 85%). This happens for big real world applications that may contain random binary data (e.g. browser), but for smaller apps situation is not so terrible and LSan still might be useful. This patch adds initial support for x86 Linux (disabled by default), ARM32 is in TODO list. We used this patch (well, ported to GCC) on our 32 bit mobile emulators and it worked pretty fine thus I'm posting it here to initiate further discussion. Differential Revision: https://reviews.llvm.org/D28609 llvm-svn: 292775
* Revert "[sancov] moving sancov rt to sancov/ directory"Mike Aizatsky2017-01-121-1/+0
| | | | | | | | This reverts commit https://reviews.llvm.org/rL291734 Reason: mac breakage http://lab.llvm.org:8080/green//job/clang-stage1-configure-RA_build/28798/consoleFull#1657087648e9a0fee5-ebcc-4238-a641-c5aa112c323e llvm-svn: 291736
* [sancov] moving sancov rt to sancov/ directoryMike Aizatsky2017-01-121-0/+1
| | | | | | | | Subscribers: kubabrecka, mgorny Differential Revision: https://reviews.llvm.org/D28541 llvm-svn: 291734
* Provide default implementations for sanitizer interface functionsFrancis Ricci2017-01-072-0/+18
| | | | | | | | | | | | | | Summary: Adds a few default implementations for weak interface functions on platforms where weak hooks are not supported. Reviewers: eugenis, samsonov, timurrrr Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28201 llvm-svn: 291313
* Ensure that only one compiler-rt component is created for lsanFrancis Ricci2017-01-061-2/+1
| | | | | | | | | | | | | | | | Summary: The lsan cmake configuration failed when targeting more than one architecture, because it would attempt to create multiple components with the same name. Ensure that only one lsan component is ever created. Reviewers: beanz, bogner Subscribers: dberris, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28151 llvm-svn: 291294
* 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
* [asan/lsan] Avoid possible deadlock in dynamic ASan runtime thread ↵Maxim Ostapenko2016-10-281-0/+1
| | | | | | | | | | | | | | | | | | | | initialization. There is possible deadlock in dynamic ASan runtime when we dlopen() shared lib which creates a thread at the global initialization stage. The scenario: 1) dlopen grabs a GI_pthread_mutex_lock in main thread. 2) main thread calls pthread_create, ASan intercepts it, calls real pthread_create and waits for the second thread to be "fully initialized". 3) Newly created thread tries to access a thread local disable_counter in LSan (to complete its "full initialization") and hangs in tls_get_addr_tail, because it also tries to acquire GI_pthread_mutex_lock. The issue is reproducible on relative recent Glibc versions e.g. 2.23. Differential Revision: https://reviews.llvm.org/D26028 llvm-svn: 285385
* [lsan] Relax check for allocator_end in ProcessGlobalRegionsCallback.Maxim Ostapenko2016-10-261-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D25945 llvm-svn: 285177
* Make lsan complain loudly when running under ptraceKostya Serebryany2016-10-131-0/+2
| | | | | | | | | | | | | | | | | | Summary: LeakSanitizer does not work with ptrace but currently it will print warnings (only under verbosity=1) and then proceed to print tons of false reports. This patch makes lsan fail hard under ptrace with a verbose message. https://github.com/google/sanitizers/issues/728 Reviewers: eugenis, vitalybuka, aizatsky Subscribers: kubabrecka, llvm-commits Differential Revision: https://reviews.llvm.org/D25538 llvm-svn: 284171
* [compiler-rt][lsan] Fix compiler error due to attribute (windows)Etienne Bergeron2016-09-231-1/+1
| | | | | | | | | | | | | | | | Summary: Window compiler is stricter for attributes location. This patch fixes a compilation error. ``` D:\src\llvm\llvm\projects\compiler-rt\lib\lsan\lsan_thread.cc(39): error C2144: syntax error: 'int' should be preceded by ';' ``` Reviewers: rnk, majnemer Subscribers: majnemer, llvm-commits, chrisha, dberris Differential Revision: https://reviews.llvm.org/D24810 llvm-svn: 282254
* [CMake] Connect Compiler-RT targets to LLVM Runtimes directoryChris Bieneman2016-08-261-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+10
| | | | | | parameter instead of 5. First, this will make the mangled names shorter. Second, this will make adding more parameters simpler. llvm-svn: 279771
* [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
* [sanitizers] introduce yet another API function: ↵Kostya Serebryany2016-06-161-0/+2
| | | | | | __sanitizer_install_malloc_and_free_hooks llvm-svn: 272943
* [asan] Turn LSan-related #if’s into regular if’s in ASan initializerKuba Brecka2016-06-071-0/+7
| | | | | | | | Removing some preprocessor #if’s in favor of regular if’s. However, we need to declare empty stub functions to avoid linker errors. Differential Revision: http://reviews.llvm.org/D20911 llvm-svn: 272047
* [LSAN] Fix test swapcontext.cc on MIPSSagar Thakur2016-05-181-2/+5
| | | | | | | | | There is no frame validity check in the slow unwinder like there is in the fast unwinder due to which lsan reports a leak even for heap allocated coroutine in the test swapcontext.cc. Since mips/linux uses slow unwindwer instead of fast unwinder, the test fails for mips/linux. Therefore adding the checks before unwinding fixes the test for mips/linux. Reviewed by aizatsky. Differential: http://reviews.llvm.org/D19961 llvm-svn: 269882
* [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
* Revert "[LSAN] Fix test swapcontext.cc on MIPS"Renato Golin2016-04-221-5/+3
| | | | | | This reverts commit r266716, as it breaks the self-hosting on Thumb2 buildbot. llvm-svn: 267158
* [LSAN] Fix test swapcontext.cc on MIPSSagar Thakur2016-04-191-3/+5
| | | | | | | | | Summary: There is no frame validity check in the slow unwinder like there is in the fast unwinder due to which lsan reports a leak even for heap allocated coroutine in the test swapcontext.cc. Since mips/linux uses slow unwindwer instead of fast unwinder, the test fails for mips/linux. Therefore adding the checks before unwinding fixes the test for mips/linux. Reviewers: samsonov, earthdok, kcc Subscribers: llvm-commits, mohit.bhakkad, jaydeep Differential: http://reviews.llvm.org/D18690 llvm-svn: 266716
* [cmake] Address Samsonov's post-commit review of r262723Filipe Cabecinhas2016-03-051-1/+1
| | | | | | | | | | Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17896 llvm-svn: 262770
* [Sanitizer] Introduce ListOfModules object and use it to replace ↵Alexey Samsonov2016-02-221-16/+19
| | | | | | | | | | | | | | | | | | | | GetListOfModules(). Summary: This removes the hard limit on the number of loaded modules (used to be 16K), and makes it easier to use LoadedModules w/o causing a memory leak: ListOfModules owns the modules, and makes sure to properly clean them in destructor. Remove filtering functionality that is only needed in one place (LSan). Reviewers: aizatsky Subscribers: llvm-commits, kcc Differential Revision: http://reviews.llvm.org/D17470 llvm-svn: 261554
* [LSan] Print more helpful error message if LSan crashes during leak detection.Alexey Samsonov2016-02-121-0/+3
| | | | llvm-svn: 260717
* [LSan] Fix a crash when LSan hits a guard page while scanning thread stack ↵Alexey Samsonov2016-02-111-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | for pointers. Summary: In some cases stack pointer register (SP) doesn't point into the thread stack: e.g. if one is using swapcontext(). In this case LSan conservatively tries to scan the whole thread stack for pointers. However, thread stack (at least in glibc implementation) may also include guard pages, causing LSan to crash when it's reading from them. One of the solutions is to use a pthread_attr_getguardsize() to adjust the calculated stack boundaries. However, here we're just using IsAccessibleMemoryRange to skip guard pages and make the code (slightly) less platform-specific. Reviewers: kcc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17116 llvm-svn: 260554
* Remove autoconf support for building runtime libraries.Chris Bieneman2016-01-261-25/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I am the punishment of God... If [autoconf] had not committed great sins, God would not have sent a punishment like me upon [it]." -Genghis Khan Reviewers: chandlerc, grosbach, bob.wilson, zaks.anna, kubabrecka, samsonov, echristo Subscribers: iains, llvm-commits Differential Revision: http://reviews.llvm.org/D16473 llvm-svn: 258863
* [LSan] Ignore all allocations made inside pthread_create.Alexey Samsonov2016-01-163-7/+30
| | | | | | | | | | | | | Thread stack/TLS may be stored by libpthread for future reuse after thread destruction, and the linked list it's stored in doesn't even hold valid pointers to the objects, the latter are calculated by obscure pointer arithmetic. With this change applied, LSan test suite passes with "use_ld_allocations" flag defaulted to "false". It still requires more testing to check if the default can be switched. llvm-svn: 257975
* [LSan] Add "use_ld_allocations" flag to disable old way of DTLS handling.Alexey Samsonov2016-01-142-4/+12
| | | | | | | | | | | This flag allows to disable old way of determining dynamic TLS by filtering out allocations from dynamic linker. This will be eventually superseded by __tls_get_addr interceptor (see r257785), after we: 1) Test it in several supported environments 2) Deal with existing problems (currently we can't find a pointer to DTV which is calloc()-ed in pthread_create). llvm-svn: 257789
* [LSan] Use __tls_get_addr interceptor to keep track of dynamic TLS.Alexey Samsonov2016-01-146-17/+50
| | | | | | | | | | | | | | | | | | | | Summary: We have a way to keep track of allocated DTLS segments: let's use it in LSan. Although this code is fragile and relies on glibc implementation details, in some cases it proves to be better than existing way of tracking DTLS in LSan: marking as "reachable" all memory chunks allocated directly by "ld". The plan is to eventually get rid of the latter, once we are sure it's safe to remove. Reviewers: kcc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16164 llvm-svn: 257785
OpenPOWER on IntegriCloud