summaryrefslogtreecommitdiff
path: root/lib/sanitizer_common/sanitizer_allocator.h
Commit message (Collapse)AuthorAgeFilesLines
* Revert r369472 and r369441Vitaly Buka2019-08-211-1/+0
| | | | | | check-sanitizer does not work on Linux git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@369495 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64] Speed-up leak and address sanitizers on AArch64 for 48-bit VMASebastian Pop2019-08-201-0/+1
| | | | | | | | | | | | | | | | | | This patch fixes https://github.com/google/sanitizers/issues/703 On a Graviton-A1 aarch64 machine with 48-bit VMA, the time spent in LSan and ASan reduced from 2.5s to 0.01s when running clang -fsanitize=leak compiler-rt/test/lsan/TestCases/sanity_check_pure_c.c && time ./a.out clang -fsanitize=address compiler-rt/test/lsan/TestCases/sanity_check_pure_c.c && time ./a.out With this patch, LSan and ASan create both the 32 and 64 allocators and select at run time between the two allocators following a global variable that is initialized at init time to whether the allocator64 can be used in the virtual address space. Differential Revision: https://reviews.llvm.org/D60243 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@369441 91177308-0d34-0410-b5e6-96231b3b80d8
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
* Introduce `AddressSpaceView` template parameter to `SizeClassAllocator32`, ↵Dan Liew2018-12-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `FlatByteMap`, and `TwoLevelByteMap`. Summary: This is a follow up patch to r346956 for the `SizeClassAllocator32` allocator. This patch makes `AddressSpaceView` a template parameter both to the `ByteMap` implementations (but makes `LocalAddressSpaceView` the default), some `AP32` implementations and is used in `SizeClassAllocator32`. The actual changes to `ByteMap` implementations and `SizeClassAllocator32` are very simple. However the patch is large because it requires changing all the `AP32` definitions, and users of those definitions. For ASan and LSan we make `AP32` and `ByteMap` templateds type that take a single `AddressSpaceView` argument. This has been done because we will instantiate the allocator with a type that isn't `LocalAddressSpaceView` in the future patches. For the allocators used in the other sanitizers (i.e. HWAsan, MSan, Scudo, and TSan) use of `LocalAddressSpaceView` is hard coded because we do not intend to instantiate the allocators with any other type. In the cases where untemplated types have become templated on a single `AddressSpaceView` parameter (e.g. `PrimaryAllocator`) their name has been changed to have a `ASVT` suffix (Address Space View Type) to indicate they are templated. The only exception to this are the `AP32` types due to the desire to keep the type name as short as possible. In order to check that template is instantiated in the correct a way a `static_assert(...)` has been added that checks that the `AddressSpaceView` type used by `Params::ByteMap::AddressSpaceView` matches the `Params::AddressSpaceView`. This uses the new `sanitizer_type_traits.h` header. rdar://problem/45284065 Reviewers: kcc, dvyukov, vitalybuka, cryptoad, eugenis, kubamracek, george.karpenkov Subscribers: mgorny, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D54904 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@349138 91177308-0d34-0410-b5e6-96231b3b80d8
* Start adding the supporting code to perform out-of-process allocatorDan Liew2018-11-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | enumeration. Summary: This patch introduces the local portion (`LocalAddressSpaceView`) of the `AddressSpaceView` abstraction and modifies the secondary allocator so that the `ForEachChunk()` method (and its callees) would work in the out-of-process case when `AddressSpaceView` is `RemoteAddressSpaceView`. The `AddressSpaceView` abstraction simply maps pointers from a target process to a pointer in the local process (via its `Load()` method). For the local (in-process) case this is a no-op. For the remote (out-of-process) case this is not a no-op. The implementation of the out-of-process `RemoteAddressSpaceView` is not included in this patch and will be introduced later. This patch is considerably simpler than the `ObjectView` abstraction used in previous patches but lacks the type safety and stricter memory management of the `ObjectView` abstraction. This patch does not introduce any tests because with `LocalAddressSpaceView` it should be a non functional change and unit tests already cover the secondary allocator. When `RemoteAddressSpaceView` is landed tests will be added to ensure that it functions as expected. rdar://problem/45284065 Reviewers: kcc, kubamracek, dvyukov, vitalybuka, cryptoad, george.karpenkov, morehouse Subscribers: #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D53975 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@346956 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizers] Remove OOM/BadRequest allocator error handling policies.Alex Shlyapnikov2018-06-201-16/+4
| | | | | | | | | | | | | | | | | | | Summary: Remove the generic error nadling policies and handle each allocator error explicitly. Although more verbose, it allows for more comprehensive, precise and actionable allocator related failure reports. This finishes up the series of changes of the particular sanitizer allocators, improves the internal allocator error reporting and removes now unused policies. Reviewers: vitalybuka, cryptoad Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D48328 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@335147 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Minor 32-bit primary improvementsKostya Kortchinsky2018-05-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For the 32-bit TransferBatch: - `SetFromArray` callers have bounds `count`, so relax the `CHECK` to `DCHECK`; - same for `Add`; - mark `CopyToArray` as `const`; For the 32-bit Primary: - `{Dea,A}llocateBatch` are only called from places that check `class_id`, relax the `CHECK` to `DCHECK`; - same for `AllocateRegion`; - remove `GetRegionBeginBySizeClass` that is not used; - use a local variable for the random shuffle state, so that the compiler can use a register instead of reading and writing to the `SizeClassInfo` at every iteration; For the 32-bit local cache: - pass the count to drain instead of doing a `Min` everytime which is at times superfluous. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D46657 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@332478 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Allow for the allocator "names" to be set by the toolsKostya Kortchinsky2018-04-131-0/+4
| | | | | | | | | | | | | | | | | | | Summary: In the same spirit of SanitizerToolName, allow the Primary & Secondary allocators to have names that can be set by the tools via PrimaryAllocatorName and SecondaryAllocatorName. Additionally, set a non-default name for Scudo. Reviewers: alekseyshl, vitalybuka Reviewed By: alekseyshl, vitalybuka Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45600 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@330055 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASan] Report proper ASan error on allocator failures instead of CHECK(0)-ingAlex Shlyapnikov2018-03-281-0/+3
| | | | | | | | | | | | | | | | | | Summary: Currently many allocator specific errors (OOM, for example) are reported as a text message and CHECK(0) termination, not stack, no details, not too helpful nor informative. To improve the situation, ASan detailed errors were defined and reported under the appropriate conditions. Issue: https://github.com/google/sanitizers/issues/887 Reviewers: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D44404 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@328722 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Random shuffling of chunks for the 32-bit Primary AllocatorKostya Kortchinsky2017-10-251-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The 64-bit primary has had random shuffling of chunks for a while, this implements it for the 32-bit primary. Scudo is currently the only user of `kRandomShuffleChunks`. This change consists of a few modifications: - move the random shuffling functions out of the 64-bit primary to `sanitizer_common.h`. Alternatively I could move them to `sanitizer_allocator.h` as they are only used in the allocator, I don't feel strongly either way; - small change in the 64-bit primary to make the `rand_state` initialization `UNLIKELY`; - addition of a `rand_state` in the 32-bit primary's `SizeClassInfo` and shuffling of chunks when populating the free list. - enabling the `random_shuffle.cpp` test on platforms using the 32-bit primary for Scudo. Some comments on why the shuffling is done that way. Initially I just implemented a `Shuffle` function in the `TransferBatch` which was simpler but I came to realize this wasn't good enough: for chunks of 10000 bytes for example, with a `CompactSizeClassMap`, a batch holds only 1 chunk, meaning shuffling the batch has no effect, while a region is usually 1MB, eg: 104 chunks of that size. So I decided to "stage" the newly gathered chunks in a temporary array that would be shuffled prior to placing the chunks in batches. The result is looping twice through n_chunks even if shuffling is not enabled, but I didn't notice any significant significant performance impact. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: srhines, llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D39244 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316596 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizers] ASan/MSan/LSan allocators set errno on failure.Alex Shlyapnikov2017-07-181-5/+0
| | | | | | | | | | | | | | | | | | | | | Summary: ASan/MSan/LSan allocators set errno on allocation failures according to malloc/calloc/etc. expected behavior. MSan allocator was refactored a bit to make its structure more similar with other allocators. Also switch Scudo allocator to the internal errno definitions. TSan allocator changes will follow. Reviewers: eugenis Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D35275 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@308344 91177308-0d34-0410-b5e6-96231b3b80d8
* MergeAlex Shlyapnikov2017-06-291-2/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306746 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizers] Operator new() interceptors always die on allocation errorAlex Shlyapnikov2017-06-281-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Operator new interceptors behavior is now controlled by their nothrow property as well as by allocator_may_return_null flag value: - allocator_may_return_null=* + new() - die on allocation error - allocator_may_return_null=0 + new(nothrow) - die on allocation error - allocator_may_return_null=1 + new(nothrow) - return null Ideally new() should throw std::bad_alloc exception, but that is not trivial to achieve, hence TODO. Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34731 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306604 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizers] Move cached allocator_may_return_null flag to sanitizer_allocatorAlex Shlyapnikov2017-06-201-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Move cached allocator_may_return_null flag to sanitizer_allocator.cc and provide API to consolidate and unify the behavior of all specific allocators. Make all sanitizers using CombinedAllocator to follow AllocatorReturnNullOrDieOnOOM() rules to behave the same way when OOM happens. When OOM happens, turn allocator_out_of_memory flag on regardless of allocator_may_return_null flag value (it used to not to be set when allocator_may_return_null == true). release_to_os_interval_ms and rss_limit_exceeded will likely be moved to sanitizer_allocator.cc too (later). Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34310 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305858 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't use internal symbolizer if we are in process of reporting Out-of-Memory.Vitaly Buka2016-09-291-1/+6
| | | | | | Reviewed by eugenis offline, as reviews.llvm.org is down. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@282805 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] better allocator stats (with rss)Kostya Serebryany2016-07-211-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@276343 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizers] split sanitizer_allocator.h into a number of smaller .h files; NFCKostya Serebryany2016-07-201-1437/+9
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@276195 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Fix sanitizer memory allocator on win64.Etienne Bergeron2016-07-071-2/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is fixing unittests for sanitizer memory allocator. There was two issues: 1) The VirtualAlloc can't reserve twice a memory range. The memory space used by the SizeClass allocator is reserved with NoAccess and pages are commited on demand (using MmapFixedOrDie). 2) The address space is allocated using two VirtualAlloc calls. The first one for the memory space, the second one for the AdditionnalSpace (after). On windows, they need to be freed separately. Reviewers: rnk Subscribers: llvm-commits, wang0109, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21900 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@274772 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Fix a crash in SizeClassAllocator32 with an out-of-range pointerKuba Brecka2016-05-021-0/+3
| | | | | | | | | | This happens on a 64-bit platform that uses SizeClassAllocator32 (e.g. ASan on AArch64). When querying a large invalid pointer, `__sanitizer_get_allocated_size(0xdeadbeefdeadbeef)`, an assertion will fail. This patch changes PointerIsMine to return false if the pointer is outside of [kSpaceBeg, kSpaceBeg + kSpaceSize). Differential Revision: http://reviews.llvm.org/D15008 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@268243 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] add a function MmapNoAccess that mmaps a protected region ↵Kostya Serebryany2016-04-231-2/+2
| | | | | | *somewhere*; use MmapNoAccess in the Allocator when SpaceBeg is not a constant. In this mode the allocator will be a bit more hardened git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@267256 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] rename MmapNoAccess to MmapFixedNoAccess; NFCKostya Serebryany2016-04-221-3/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@267253 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] partially un-revert r267094: Allow the sanitizer allocator to ↵Kostya Serebryany2016-04-221-19/+39
| | | | | | use a non-fixed address range. An allocator with a non-fixed address range will be attack-resistan. NFC for the sanitizers at this point. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@267252 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[sanitizer] Allow the sanitizer allocator to use a non-fixed address ↵Renato Golin2016-04-221-39/+19
| | | | | | | | | range. An allocator with a non-fixed address range will be attack-resistan. NFC for the sanitizers at this point." This reverts commit r267094, because it broke a lot of MSAN tests in AArch64. Being NFC and all, this needs some deeper investigation before it goes in again. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@267136 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Allow the sanitizer allocator to use a non-fixed address range. ↵Kostya Serebryany2016-04-221-19/+39
| | | | | | An allocator with a non-fixed address range will be attack-resistan. NFC for the sanitizers at this point. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@267094 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Fix Clang-tidy modernize-use-nullptr warnings in ↵Kostya Serebryany2015-09-291-19/+19
| | | | | | lib/sanitizer_common headers, unify closing inclusion guards. Patch by Eugene Zelenko git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@248816 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] [tsan] Enable TSan for AArch64/42-bit VMAAdhemerval Zanella2015-08-281-0/+4
| | | | | | | | | | | | This patch adds support for tsan on aarch64-linux with 42-bit VMA (current default config for 64K pagesize kernels). The support is enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time for both clang/llvm and compiler-rt. The default VMA is 39 bits. It also enabled tsan for previous supported VMA (39). git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@246330 91177308-0d34-0410-b5e6-96231b3b80d8
* Split Mprotect into MmapNoAccess and MprotectNoAccess to be more portableTimur Iskhodzhanov2015-04-101-1/+1
| | | | | | | | | On Windows, we have to know if a memory to be protected is mapped or not. On POSIX, Mprotect was semantically different from mprotect most people know. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@234602 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] use the right memory orderKostya Serebryany2015-01-091-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@225546 91177308-0d34-0410-b5e6-96231b3b80d8
* [asan] add a flag soft_rss_limit_mbKostya Serebryany2015-01-061-1/+13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@225323 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASan] Change activation strategy.Alexey Samsonov2014-12-191-1/+5
| | | | | | | | | | | Now ASan deactivation doesn't modify common or ASan-specific runtime flags. Flags stay constant after initialization, and "deactivation" instead stashes initialized runtime state, and deactivates the runtime. Activation then just restores the original state (possibly, overriden by some activation flags provided in system property on Android). git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@224614 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Rename InitIfLinkerInitialized to InitLinkerInitialized.Sergey Matveev2014-12-191-8/+8
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@224577 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] add CombinedAllocator::InitIfLinkerInitialized and use it in ↵Kostya Serebryany2014-12-171-6/+24
| | | | | | lsan: speeds up lsan start-up time by ~25% git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@224469 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizer] Introduce Allocator::may_return_null bool flag.Alexey Samsonov2014-12-121-7/+34
| | | | | | | | | | | | | | | | | | | | Summary: Turn "allocator_may_return_null" common flag into an Allocator::may_return_null bool flag. We want to make sure that common flags are immutable after initialization. There are cases when we want to change this flag in the allocator at runtime: e.g. in unit tests and during ASan activation on Android. Test Plan: regression test suite, real-life applications Reviewers: kcc, eugenis Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6623 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@224148 91177308-0d34-0410-b5e6-96231b3b80d8
* tsan: support mmap(MAP_32BIT)Dmitry Vyukov2014-10-241-5/+5
| | | | | | | | | | | Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@220571 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Add a bunch of sanity checks.Evgeniy Stepanov2014-10-231-1/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@220528 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix apparent thinko in r209744: allocator stats can be zeroAlexey Samsonov2014-06-301-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@212071 91177308-0d34-0410-b5e6-96231b3b80d8
* tsan: do not use 64-bit atomics in allocator codeDmitry Vyukov2014-05-281-18/+24
| | | | | | | | 64-bit atomics make porting of asan to 32-bits platforms problematic. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@209744 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] revert r200197: the buggy kernel ↵Kostya Serebryany2014-01-271-1/+1
| | | | | | (https://bugzilla.kernel.org/show_bug.cgi?id=67651) is almost unusable with asan even with this workaround (too slow), so this workaround makes no sense. The asan/msan bootstrap bot was changed to use a non-buggy kernel git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200217 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] increase the mmap granularity in sanitizer allocator from 2^16 ↵Kostya Serebryany2014-01-271-1/+1
| | | | | | to 2^18. This is a partial workaround for the fresh Kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=67651 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200197 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Implement TwoLevelByteMap and use it for the internal allocator ↵Kostya Serebryany2013-11-251-1/+63
| | | | | | | | | | | | | | | | | | | | on 64-bit. Summary: Implement TwoLevelByteMap and use it for the internal allocator on 64-bit. This reduces bss on 64-bit by ~8Mb because we don't use FlatByteMap on 64-bits any more. Dmitry, please check my understanding of atomics. Reviewers: dvyukov Reviewed By: dvyukov CC: samsonov, llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2259 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@195637 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Do not clear memory which comes from secondary allocator.Sergey Matveev2013-11-241-2/+3
| | | | | | Secondary allocator is mmap-based, so the memory is already zeroed. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@195571 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] use 16-byte aligned bzero in performance critical place (mostly ↵Kostya Serebryany2013-11-231-1/+1
| | | | | | for lsan) git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@195549 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename SpinMutex::AssertHeld to CheckLocked, for consistency with BlockingMutex.Peter Collingbourne2013-10-251-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@193447 91177308-0d34-0410-b5e6-96231b3b80d8
* [asan] Fix a deadlock between asan's allocator and lsanKostya Serebryany2013-10-171-0/+1
| | | | | | | | | | | | | | | | Summary: This fixes a deadlock which happens in lsan on a large memalign-allocated chunk that resides in lsan's root set. Reviewers: samsonov, earthdok Reviewed By: earthdok CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1957 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@192885 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] make the allocator crash instead of returning 0 on huge size ↵Kostya Serebryany2013-09-061-2/+5
| | | | | | (controlled by the allocator_may_return_null flag) git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@190127 91177308-0d34-0410-b5e6-96231b3b80d8
* tsan: better diagnostics for invalid addresses passed to free()Dmitry Vyukov2013-08-081-1/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@187980 91177308-0d34-0410-b5e6-96231b3b80d8
* Lint fixesAlexey Samsonov2013-08-051-1/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@187726 91177308-0d34-0410-b5e6-96231b3b80d8
* [msan] Allocator statistics interface and malloc hooks.Evgeniy Stepanov2013-08-021-5/+5
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@187653 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert to C-style callbacks for iteration over allocator chunks.Sergey Matveev2013-06-241-33/+28
| | | | | | | Also clean up LSan code, fix some comments and replace void* with uptr to bring down the number of reinterpret_casts. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@184700 91177308-0d34-0410-b5e6-96231b3b80d8
* [lsan] Implement __lsan_ignore_object().Sergey Matveev2013-06-061-9/+9
| | | | | | Leak annotation similar to HeapChecker's IgnoreObject(). git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@183412 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status