summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/sanitizer_common/sanitizer_allocator_internal.h
Commit message (Collapse)AuthorAgeFilesLines
* [sanitizer][NFC] Set LargeMmapAllocator type from PrimaryAllocatorVitaly Buka2019-05-011-5/+2
| | | | | | | | | | | | | | They need to have same AddressSpaceView and MapUnmapCallback. Reviewers: eugenis Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61168 llvm-svn: 359719
* [sanitizer][NFC] Get type of AllocatorCache from CombinedAllocatorVitaly Buka2019-05-011-5/+3
| | | | | | | | | | | | | | Reviewers: eugenis, cryptoad, kcc Reviewed By: kcc Subscribers: kcc, kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61155 llvm-svn: 359715
* [sanitizer] Implement reallocarray.Evgeniy Stepanov2019-05-011-1/+3
| | | | | | | | | | | | | | | | Summary: It's a cross of calloc and realloc. Sanitizers implement calloc-like check for size overflow. Reviewers: vitalybuka, kcc Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61108 llvm-svn: 359708
* [sanitizer] Calculate SizeClassAllocator32::ByteMap type from ↵Vitaly Buka2019-04-271-10/+1
| | | | | | | | | | | | | | Params::kSpaceSize and Params::kRegionSizeLog Reviewers: eugenis Subscribers: kubamracek, cryptoad, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61206 llvm-svn: 359374
* [lsan] Use SANITIZER_WORDSIZE when selecting ByteMapVitaly Buka2019-04-261-1/+1
| | | | | | | Originally this code was added for 64-bit platform and it was never update. Add static_assert to validate type of ByteMap. llvm-svn: 359286
* Revert "[lsan] Use SANITIZER_WORDSIZE when selecting ByteMap"Vitaly Buka2019-04-261-1/+1
| | | | | | | | New static_assert fails on a bot. This reverts commit r359269. llvm-svn: 359276
* [lsan] Use SANITIZER_WORDSIZE when selecting ByteMapVitaly Buka2019-04-261-1/+1
| | | | | | | Originally this code as added for 64-bit platform and was never changed. Add static_assert to make sure that we have correct map on all platforms. llvm-svn: 359269
* 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. llvm-svn: 351636
* Introduce `AddressSpaceView` template parameter to `SizeClassAllocator32`, ↵Dan Liew2018-12-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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 llvm-svn: 349138
* [sanitizer] Remove low-hanging-fruit dead codeKostya Kortchinsky2018-04-171-9/+0
| | | | | | | | | | | | | | | | | Summary: Going through the dead code findings, the code removed in this CL appears to be pretty straightforward to remove, and seems to be some leftover from previous refactors. Reviewers: alekseyshl, eugenis Reviewed By: alekseyshl Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45704 llvm-svn: 330190
* [Sanitizers] Increase allocated chunk limit for LargeMmapAllocatorAlex Shlyapnikov2018-02-241-2/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: There are applications out there which allocate more than 1 << 18 large chunks of memory (those handled by LargeMmapAllocator, aka secondary allocator). For 64 bits, secondary allocator stores allocated chunks in a growing on demand region of memory, growing in blocks of 128K, up to 1 << 20 chunks total. Sanitizer internal allocator's secondary uses fixed size array storing up to 1 << 15 chunks (down to 256K from 2Mb of memory used for that array). Nothing is changed for 32 bits, chunks are still stored in the fixed size array (up to 1 << 15 chunks). Reviewers: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D43693 llvm-svn: 326007
* [Sanitizers] Make common allocator agnostic to failure handling modes.Alex Shlyapnikov2018-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Make common allocator agnostic to failure handling modes and move the decision up to the particular sanitizer's allocator, where the context is available (call stack, parameters, return nullptr/crash mode etc.) It simplifies the common allocator and allows the particular sanitizer's allocator to generate more specific and detailed error reports (which will be implemented later). The behavior is largely the same, except one case, the violation of the common allocator's check for "size + alignment" overflow is now reportied as OOM instead of "bad request". It feels like a worthy tradeoff and "size + alignment" is huge in this case anyway (thus, can be interpreted as not enough memory to satisfy the request). There's also a Report() statement added there. Reviewers: eugenis Subscribers: kubamracek, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D42198 llvm-svn: 322784
* [Sanitizers] Move cached allocator_may_return_null flag to sanitizer_allocatorAlex Shlyapnikov2017-06-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 305858
* [sanitizer] Change SizeClassAllocator32 to accept just one templateKostya Kortchinsky2017-05-151-9/+13
| | | | | | | | | | | | | | | | | | | | | Summary: With rL279771, SizeClassAllocator64 was changed to accept only one template instead of 5, for the following reasons: "First, this will make the mangled names shorter. Second, this will make adding more parameters simpler". This patch mirrors that work for SizeClassAllocator32. This is in preparation for introducing the randomization of chunks in the 32-bit SizeClassAllocator in a later patch. Reviewers: kcc, alekseyshl, dvyukov Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D33141 llvm-svn: 303071
* [compiler-rt] Do not introduce __sanitizer namespace globallyAnna Zaks2016-09-151-2/+2
| | | | | | | | | | | | 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
* [tsan] Switch to InternalAlloc everywhere __libc_malloc is currently usedKuba Brecka2016-06-061-1/+6
| | | | | | | | | | 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
* [sanitizer] Fix Clang-tidy modernize-use-nullptr warnings in ↵Kostya Serebryany2015-09-291-5/+5
| | | | | | lib/sanitizer_common headers, unify closing inclusion guards. Patch by Eugene Zelenko llvm-svn: 248816
* [sanitizer] Flag parser rewrite.Evgeniy Stepanov2015-01-151-0/+9
| | | | | | | The new parser is a lot stricter about syntax, reports unrecognized flags, and will make it easier to implemented some of the planned features. llvm-svn: 226169
* tsan: fix crash when a program registers zillions of atexit callbacksDmitry Vyukov2014-09-171-13/+1
| | | | | | | | | | I don't remember that crash on mmap in internal allocator ever yielded anything useful, only crashes in rare wierd untested situations. One of the reasons for crash was to catch if tsan starts allocating clocks using mmap. Tsan does not allocate clocks using internal_alloc anymore. Solve it once and for all by allowing mmaps. llvm-svn: 217929
* tsan: reduce internal allocator region from 16M to 1MDmitry Vyukov2014-07-261-2/+1
| | | | | | | | 16M regions can waste almost 1G for nothing. Since region size is used only during initial heap growth, it's unclear why we even need such huge regions. llvm-svn: 214027
* tsan: remove meta from internal allocatorDmitry Vyukov2014-07-261-1/+1
| | | | | | I am puzzled why it is even there. llvm-svn: 214026
* tsan: add new line at the end of error messageDmitry Vyukov2014-02-281-2/+2
| | | | llvm-svn: 202470
* [asan] allow asan to use SizeClassAllocator32 on a 64-bit platform (if ↵Kostya Serebryany2013-12-261-2/+1
| | | | | | SANITIZER_CAN_USE_ALLOCATOR64=0). No functionality change by default is intended llvm-svn: 198044
* [sanitizer] Implement TwoLevelByteMap and use it for the internal allocator ↵Kostya Serebryany2013-11-251-5/+9
| | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 195637
* [sanitizer] Use raw check in internal allocator to prevent self-deadlocks. ↵Alexey Samsonov2013-05-291-2/+2
| | | | | | Try to fix Windows build. llvm-svn: 182840
* Exclude sanitizer_nolibc_test from TSan test run. Fix lint warningsAlexey Samsonov2013-05-291-1/+1
| | | | llvm-svn: 182837
* Make InternalAlloc/InternalFree in sanitizer runtimes libc-free by switching ↵Alexey Samsonov2013-05-291-0/+64
to a custom allocator. llvm-svn: 182836
OpenPOWER on IntegriCloud