summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/sanitizer_common/tests/sanitizer_allocator_test.cc
Commit message (Collapse)AuthorAgeFilesLines
* compiler-rt: Rename .cc file in lib/sanitizer_common/tests to .cppNico Weber2019-07-311-1407/+0
| | | | | | | | | | | See https://reviews.llvm.org/D58620 for discussion, and for the commands I ran. In addition I also ran for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $(basename $f) . ; done and manually updated references to renamed files found by that. llvm-svn: 367467
* [sanitizer][NFC] Remove unneeded SizeClassAllocatorLocalCacheVitaly Buka2019-05-011-21/+16
| | | | llvm-svn: 359729
* [sanitizer][NFC] Set LargeMmapAllocator type from PrimaryAllocatorVitaly Buka2019-05-011-7/+7
| | | | | | | | | | | | | | 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-21/+8
| | | | | | | | | | | | | | 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] Calculate SizeClassAllocator32::ByteMap type from ↵Vitaly Buka2019-04-271-8/+3
| | | | | | | | | | | | | | 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
* [NFC] Remove ::kForTest from AP64, it does not use it.Vitaly Buka2019-04-261-7/+7
| | | | llvm-svn: 359323
* [lsan] Use SANITIZER_WORDSIZE when selecting ByteMapVitaly Buka2019-04-261-10/+11
| | | | | | | 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-11/+10
| | | | | | | | New static_assert fails on a bot. This reverts commit r359269. llvm-svn: 359276
* [lsan] Use SANITIZER_WORDSIZE when selecting ByteMapVitaly Buka2019-04-261-10/+11
| | | | | | | 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
* Fix invalid code that Clang trunk will soon diagnose.Richard Smith2019-02-151-1/+1
| | | | | | | | | | | | | There is an ambiguity between ::SizeClassMap (the typedef declared near the start of this file) and __sanitizer::SizeClassMap (found by the 'using namespace __sanitizer;' near the start of this file). Historically a Clang bug has meant that the error was not diagnosed, but soon Clang will start diagnosing it. Explicitly qualify this use of SizeClassMap so that it finds __sanitizer::SizeClassMap rather than being ill-formed due to ambiguity. llvm-svn: 354174
* 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 `SizeClassAllocator64`.Dan Liew2018-12-211-7/+39
| | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow up patch to r349138. This patch makes a `AddressSpaceView` a type declaration in the allocator parameters used by `SizeClassAllocator64`. For ASan, LSan, and the unit tests the AP64 declarations have been made templated so that `AddressSpaceView` can be changed at compile time. For the other sanitizers we just hard-code `LocalAddressSpaceView` because we have no plans to use these allocators in an out-of-process manner. rdar://problem/45284065 Reviewers: kcc, dvyukov, vitalybuka, cryptoad, eugenis, kubamracek, george.karpenkov Subscribers: #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D55764 llvm-svn: 349954
* Introduce `AddressSpaceView` template parameter to `SizeClassAllocator32`, ↵Dan Liew2018-12-141-8/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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
* [SanitizerCommon] Test `CombinedAllocator::ForEachChunk()` in unit tests.Dan Liew2018-12-041-0/+16
| | | | | | | | | | | | | | Summary: Previously we weren't testing this function in the unit tests. Reviewers: kcc, cryptoad, dvyukov, eugenis, kubamracek Subscribers: #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D54861 llvm-svn: 348260
* [sanitizer] Disable failing Android test after D52371Kostya Kortchinsky2018-09-271-4/+5
| | | | | | | | | | | | | | | | | Summary: The default values used for Space/Size for the new SizeClassMap do not work with Android. The Compact map appears to be in the same boat. Disable the test on Android for now to turn the bots green, but there is no reason Compact & Dense should not have an Android test. Added a FIXME, I will revisit this soon. Reviewers: eugenis Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52623 llvm-svn: 343252
* [sanitizer] Introduce a new SizeClassMap with minimal amount of cached entriesKostya Kortchinsky2018-09-271-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: _Note_: I am not attached to the name `DenseSizeClassMap`, so if someone has a better idea, feel free to suggest it. The current pre-defined `SizeClassMap` hold a decent amount of cached entries, either in cheer number of, or in amount of memory cached. Empirical testing shows that more compact per-class arrays (whose sizes are directly correlated to the number of cached entries) are beneficial to performances, particularly in highly threaded environments. The new proposed `SizeClassMap` has the following properties: ``` c00 => s: 0 diff: +0 00% l 0 cached: 0 0; id 0 c01 => s: 16 diff: +16 00% l 4 cached: 8 128; id 1 c02 => s: 32 diff: +16 100% l 5 cached: 8 256; id 2 c03 => s: 48 diff: +16 50% l 5 cached: 8 384; id 3 c04 => s: 64 diff: +16 33% l 6 cached: 8 512; id 4 c05 => s: 80 diff: +16 25% l 6 cached: 8 640; id 5 c06 => s: 96 diff: +16 20% l 6 cached: 8 768; id 6 c07 => s: 112 diff: +16 16% l 6 cached: 8 896; id 7 c08 => s: 128 diff: +16 14% l 7 cached: 8 1024; id 8 c09 => s: 144 diff: +16 12% l 7 cached: 7 1008; id 9 c10 => s: 160 diff: +16 11% l 7 cached: 6 960; id 10 c11 => s: 176 diff: +16 10% l 7 cached: 5 880; id 11 c12 => s: 192 diff: +16 09% l 7 cached: 5 960; id 12 c13 => s: 208 diff: +16 08% l 7 cached: 4 832; id 13 c14 => s: 224 diff: +16 07% l 7 cached: 4 896; id 14 c15 => s: 240 diff: +16 07% l 7 cached: 4 960; id 15 c16 => s: 256 diff: +16 06% l 8 cached: 4 1024; id 16 c17 => s: 320 diff: +64 25% l 8 cached: 3 960; id 49 c18 => s: 384 diff: +64 20% l 8 cached: 2 768; id 50 c19 => s: 448 diff: +64 16% l 8 cached: 2 896; id 51 c20 => s: 512 diff: +64 14% l 9 cached: 2 1024; id 48 c21 => s: 640 diff: +128 25% l 9 cached: 1 640; id 49 c22 => s: 768 diff: +128 20% l 9 cached: 1 768; id 50 c23 => s: 896 diff: +128 16% l 9 cached: 1 896; id 51 c24 => s: 1024 diff: +128 14% l 10 cached: 1 1024; id 48 c25 => s: 1280 diff: +256 25% l 10 cached: 1 1280; id 49 c26 => s: 1536 diff: +256 20% l 10 cached: 1 1536; id 50 c27 => s: 1792 diff: +256 16% l 10 cached: 1 1792; id 51 c28 => s: 2048 diff: +256 14% l 11 cached: 1 2048; id 48 c29 => s: 2560 diff: +512 25% l 11 cached: 1 2560; id 49 c30 => s: 3072 diff: +512 20% l 11 cached: 1 3072; id 50 c31 => s: 3584 diff: +512 16% l 11 cached: 1 3584; id 51 c32 => s: 4096 diff: +512 14% l 12 cached: 1 4096; id 48 c33 => s: 5120 diff: +1024 25% l 12 cached: 1 5120; id 49 c34 => s: 6144 diff: +1024 20% l 12 cached: 1 6144; id 50 c35 => s: 7168 diff: +1024 16% l 12 cached: 1 7168; id 51 c36 => s: 8192 diff: +1024 14% l 13 cached: 1 8192; id 48 c37 => s: 10240 diff: +2048 25% l 13 cached: 1 10240; id 49 c38 => s: 12288 diff: +2048 20% l 13 cached: 1 12288; id 50 c39 => s: 14336 diff: +2048 16% l 13 cached: 1 14336; id 51 c40 => s: 16384 diff: +2048 14% l 14 cached: 1 16384; id 48 c41 => s: 20480 diff: +4096 25% l 14 cached: 1 20480; id 49 c42 => s: 24576 diff: +4096 20% l 14 cached: 1 24576; id 50 c43 => s: 28672 diff: +4096 16% l 14 cached: 1 28672; id 51 c44 => s: 32768 diff: +4096 14% l 15 cached: 1 32768; id 48 c45 => s: 40960 diff: +8192 25% l 15 cached: 1 40960; id 49 c46 => s: 49152 diff: +8192 20% l 15 cached: 1 49152; id 50 c47 => s: 57344 diff: +8192 16% l 15 cached: 1 57344; id 51 c48 => s: 65536 diff: +8192 14% l 16 cached: 1 65536; id 48 c49 => s: 81920 diff: +16384 25% l 16 cached: 1 81920; id 49 c50 => s: 98304 diff: +16384 20% l 16 cached: 1 98304; id 50 c51 => s: 114688 diff: +16384 16% l 16 cached: 1 114688; id 51 c52 => s: 131072 diff: +16384 14% l 17 cached: 1 131072; id 48 c53 => s: 64 diff: +0 00% l 0 cached: 8 512; id 4 Total cached: 864928 (152/432) ``` It holds a bit less of 1MB of cached entries at most, and the cache fits in a page. The plan is to use this map by default for Scudo once we make sure that there is no unforeseen impact for any of current use case. Benchmarks give the most increase in performance (with Scudo) when looking at highly threaded/contentious environments. For example, rcp2-benchmark experiences a 10K QPS increase (~3%), and a decrease of 50MB for the max RSS (~10%). On platforms like Android where we only have a couple of caches, performance remain similar. Reviewers: eugenis, kcc Reviewed By: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52371 llvm-svn: 343246
* [sanitizer] s/TestOnlyInit/Init for the allocator ByteMap (NFC)Kostya Kortchinsky2018-05-071-2/+2
| | | | | | | | | | | | | | | | | Summary: The `TestOnlyInit` function of `{Flat,TwoLevel}ByteMap` seems to be a misnomer since the function is used outside of tests as well, namely in `SizeClassAllocator32::Init`. Rename it to `Init` and update the callers. Reviewers: alekseyshl, vitalybuka Reviewed By: vitalybuka Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D46408 llvm-svn: 331662
* [sanitizer] Replace InternalScopedBuffer with InternalMmapVectorVitaly Buka2018-05-071-2/+2
| | | | llvm-svn: 331618
* [sanitizer] Make InternalScopedBuffer::size() behavior similar to vector.Vitaly Buka2018-05-071-2/+2
| | | | llvm-svn: 331612
* [Sanitizers] Make common allocator agnostic to failure handling modes.Alex Shlyapnikov2018-01-171-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Sanitizer] Disable compact size class tests on AndroidAlex Shlyapnikov2017-09-271-0/+2
| | | | | | | Fixing test failure on Android introduced in D38245. Compact size class maps defined there are not to be used on Android. llvm-svn: 314318
* [Sanitizers] Allocator: new "release memory to OS" implementationAlex Shlyapnikov2017-09-271-0/+275
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current implementation of the allocator returning freed memory back to OS (controlled by allocator_release_to_os_interval_ms flag) requires sorting of the free chunks list, which has two major issues, first, when free list grows to millions of chunks, sorting, even the fastest one, is just too slow, and second, sorting chunks in place is unacceptable for Scudo allocator as it makes allocations more predictable and less secure. The proposed approach is linear in complexity (altough requires quite a bit more temporary memory). The idea is to count the number of free chunks on each memory page and release pages containing free chunks only. It requires one iteration over the free list of chunks and one iteration over the array of page counters. The obvious disadvantage is the allocation of the array of the counters, but even in the worst case we support (4T allocator space, 64 buckets, 16 bytes bucket size, full free list, which leads to 2 bytes per page counter and ~17M page counters), requires just about 34Mb of the intermediate buffer (comparing to ~64Gb of actually allocated chunks) and usually it stays under 100K and released after each use. It is expected to be a relatively rare event, releasing memory back to OS, keeping the buffer between those runs and added complexity of the bookkeeping seems unnesessary here (it can always be improved later, though, never say never). The most interesting problem here is how to calculate the number of chunks falling into each memory page in the bucket. Skipping all the details, there are three cases when the number of chunks per page is constant: 1) P >= C, P % C == 0 --> N = P / C 2) C > P , C % P == 0 --> N = 1 3) C <= P, P % C != 0 && C % (P % C) == 0 --> N = P / C + 1 where P is page size, C is chunk size and N is the number of chunks per page and the rest of the cases, where the number of chunks per page is calculated on the go, during the page counter array iteration. Among the rest, there are still cases where N can be deduced from the page index, but they require not that much less calculations per page than the current "brute force" way and 2/3 of the buckets fall into the first three categories anyway, so, for the sake of simplicity, it was decided to stick to those two variations. It can always be refined and improved later, should we see that brute force way slows us down unacceptably. Reviewers: eugenis, cryptoad, dvyukov Subscribers: kubamracek, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D38245 llvm-svn: 314311
* [sanitizer] Re-introduce kUseSeparateSizeClassForBatch for the 32-bit PrimaryKostya Kortchinsky2017-08-281-0/+17
| | | | | | | | | | | | | | | | | | | | | | | Summary: Currently `TransferBatch` are located within the same memory regions as "regular" chunks. This is not ideal for security: they make for an interesting target to overwrite, and are not protected by the frontend (namely, Scudo). To solve this, we re-introduce `kUseSeparateSizeClassForBatch` for the 32-bit Primary allowing for `TransferBatch` to end up in their own memory region. Currently only Scudo would use this new feature, the default behavior remains unchanged. The separate `kBatchClassID` was used for a brief period of time previously but removed when the 64-bit ended up using the "free array". Reviewers: alekseyshl, kcc, eugenis Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D37082 llvm-svn: 311891
* [Sanitizers] 64 bit allocator respects allocator_may_return_null flagAlex Shlyapnikov2017-06-261-16/+18
| | | | | | | | | | | | | | | | Summary: Make SizeClassAllocator64 return nullptr when it encounters OOM, which allows the entire sanitizer's allocator to follow allocator_may_return_null=1 policy (LargeMmapAllocator: D34243, SizeClassAllocator64: D34433). Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34540 llvm-svn: 306342
* [Sanitizers] Move cached allocator_may_return_null flag to sanitizer_allocatorAlex Shlyapnikov2017-06-201-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | 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-15/+23
| | | | | | | | | | | | | | | | | | | | | 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
* [asan] replace std::random_shuffle with std::shuffle in tests since ↵Kostya Serebryany2017-02-071-1/+3
| | | | | | std::random_shuffle is being deprecated in C++17; NFC llvm-svn: 294370
* Return memory to OS right after free (not in the async thread).Evgeniy Stepanov2016-11-291-12/+12
| | | | | | | | | | | | | | | | | | 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] Reenable 64-bit allocator on android/aarch64.Evgeniy Stepanov2016-09-151-15/+36
| | | | | | This is a re-commit of r281371, with updated tests. llvm-svn: 281674
* [compiler-rt] Do not introduce __sanitizer namespace globallyAnna Zaks2016-09-151-0/+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
* [sanitizer] Test the allocator with the ASan win64 memory constantsReid Kleckner2016-09-151-2/+2
| | | | | | | | These got out of sync and the tests were failing for me locally. We assume a 47 bit address space in ASan, so we should do the same in the tests. llvm-svn: 281622
* [sanitizer] fix an allocator bug where the allocated memory may overlap with ↵Kostya Serebryany2016-09-091-1/+18
| | | | | | the free array (kudos to Kostya Korcthinsky). Also make sure that the allocator does not mmap more than requested. Test both. llvm-svn: 281103
* [sanitizer] extend SizeClassMap to take more template parameters, add ↵Kostya Serebryany2016-08-311-10/+41
| | | | | | VeryCompactSizeClassMap for testing purposes llvm-svn: 280266
* [sanitizer] enable random shuffling the memory chunks inside the allocator, ↵Kostya Serebryany2016-08-261-0/+5
| | | | | | 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-12/+46
| | | | | | parameter instead of 5. First, this will make the mangled names shorter. Second, this will make adding more parameters simpler. llvm-svn: 279771
* [sanitizer] re-apply r279572 and r279595 reverted in r279643: change the ↵Kostya Serebryany2016-08-241-5/+12
| | | | | | 64-bit allocator to use a single array for free-d chunks instead of a lock-free linked list of tranfer batches. This change simplifies the code, makes the allocator more 'hardened', and will allow simpler code to release RAM to OS. This may also slowdown malloc stress tests due to lock contension, but I did not observe noticeable slowdown on various real multi-threaded benchmarks. llvm-svn: 279664
* Revert r279572 "[sanitizer] change the 64-bit..." because of failures on ubsanVitaly Buka2016-08-241-12/+5
| | | | | | This reverts commit r279572 and r279595. llvm-svn: 279643
* [sanitizer] change the 64-bit allocator to use a single array for free-d ↵Kostya Serebryany2016-08-231-5/+12
| | | | | | chunks instead of a lock-free linked list of tranfer batches. This change simplifies the code, makes the allocator more 'hardened', and will allow simpler code to release RAM to OS. This may also slowdown malloc stress tests due to lock contension, but I did not observe noticeable slowdown on various real multi-threaded benchmarks. llvm-svn: 279572
* [sanitizer] use 32-bit offset instead of 64-bit pointers in the 64-bit ↵Kostya Serebryany2016-08-091-1/+1
| | | | | | allocator's transfer batches. This saves 2x memory for the transfer batches (up to ~1.5% overall in some cases) llvm-svn: 278179
* [sanitizer] allocator: move TransferBatch into ↵Kostya Serebryany2016-08-061-1/+1
| | | | | | SizeClassAllocator64/SizeClassAllocator32 because we actually need different iplementations for the 64- and 32-bit case. NFC; the following patches will make the TransferBatch implementations differ llvm-svn: 277899
* Disable a few more flaky asan64 tests.Nico Weber2016-08-051-0/+12
| | | | llvm-svn: 277886
* Disable a few win asan64 tests that don't reliably pass, ↵Nico Weber2016-08-051-0/+12
| | | | | | https://reviews.llvm.org/D23230 llvm-svn: 277882
* [compiler-rt] Fix memory allocator for dynamic address spaceEtienne Bergeron2016-08-041-1/+31
| | | | | | | | | | | | | | | | | | | | | | | Summary: The sanitizer allocators can works with a dynamic address space (i.e. specified with ~0ULL). Unfortunately, the code was broken on GetMetadata and GetChunkIdx. The current patch is moving the Win64 memory test to a dynamic address space. There is a migration to move every concept to a dynamic address space on windows. To have a better coverage, the unittest are now testing dynamic address space on other platforms too. Reviewers: rnk, kcc Subscribers: kubabrecka, dberris, llvm-commits, chrisha Differential Revision: https://reviews.llvm.org/D23170 llvm-svn: 277745
* [sanitizer] Try to fix LargeMmapAllocator test on WindowsReid Kleckner2016-07-261-2/+4
| | | | | | | | | | | | | This test attempts to allocate 100 512MB aligned pages of memory. This is implemented in the usual way by allocating size + alignment bytes and aligning the result. As a result, this test allocates 51.2GB of memory. Windows allocates swap for all memory allocated, and our bots do not have this much swap available. Avoid the failure by using a more reasonable alignment, like 16MB, as we do on 32-bit. llvm-svn: 276779
* Try to fix more Windows portability issues in sanitizer testsReid Kleckner2016-07-221-2/+6
| | | | | | | | | | | | | | Add a %stdcxx11 lit substitution for -std=c++11. Windows defaults to -std=c++14 when VS 2015 is used because the STL requires it. Harcoding -std=c++11 in the ASan tests actually downgrades the C++ standard level, leading to test failures. Relax a FileCheck pattern in use-after-scope-types.cc. Disable the sanitizer_common OOM tests. They fail on bots with low swap, and cause other concurrently running tests to OOM. llvm-svn: 276454
* [sanitizer] allocator: remove kPopulateSize and only use ↵Kostya Serebryany2016-07-211-1/+1
| | | | | | SizeClassMap::MaxCached; ensure that TransferBatch size is a power of two, refactor TransferBatch creation/destruction into separate functions. llvm-svn: 276318
* [compiler-rt] Fix sanitizer memory allocator on win64.Etienne Bergeron2016-07-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 274772
* [compiler-rt] Fix AllocatorCacheDeallocNewThread unittestEtienne Bergeron2016-07-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The unittest was not freeing the mapped memory. ``` Repeating all tests (iteration 1) . . . Note: Google Test filter = Allocator.AllocatorCacheDeallocNewThread [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from Allocator [ RUN ] Allocator.AllocatorCacheDeallocNewThread [ OK ] Allocator.AllocatorCacheDeallocNewThread (3 ms) [----------] 1 test from Allocator (4 ms total) [----------] Global test environment tear-down [==========] 1 test from 1 test case ran. (5 ms total) [ PASSED ] 1 test. Repeating all tests (iteration 2) . . . Note: Google Test filter = Allocator.AllocatorCacheDeallocNewThread [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from Allocator [ RUN ] Allocator.AllocatorCacheDeallocNewThread ==4504==WARNING: SanitizerTool failed to mprotect 0x010000003000 (1099511640064) bytes at 0x010000000000 (error code: 48 7) ==4504==Sanitizer CHECK failed: D:/src/llvm/llvm/projects/compiler-rt/lib\sanitizer_common/sanitizer_allocator.h:329 ((kSpaceBeg)) == ((reinterpret_cast<uptr>( MmapFixedNoAccess(kSpaceBeg, TotalSpaceSize)))) (1099511627776, 0) ``` Reviewers: rnk Subscribers: llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D22094 llvm-svn: 274764
* [compiler-rt] Re-active unittest previously broken on windows.Etienne Bergeron2016-06-301-4/+0
| | | | | | | | | | | | Summary: These tests are working fine. Reviewers: rnk Subscribers: kubabrecka, wang0109, llvm-commits, chrisha Differential Revision: http://reviews.llvm.org/D21905 llvm-svn: 274265
* [sanitizer] [SystemZ] Add virtual space size.Marcin Koscielnicki2016-04-141-0/+4
| | | | | | | | | This teaches sanitizer_common about s390 and s390x virtual space size. s390 is unusual in that it has 31-bit virtual space. Differential Revision: http://reviews.llvm.org/D18896 llvm-svn: 266296
OpenPOWER on IntegriCloud