Summary:
We found a nondeterministic behavior when doing online profile merging
for multi-process applications. The application forks a sub-process and
sub-process sets to get SIGKILL when the parent process exits,
The first process gets the lock, and dumps the profile. The second one
will mmap the file, do the merge and write out the file. Note that before
the merged write, we truncate the profile.
Depending on the timing, the child process might be terminated
abnormally when the parent exits first. If this happens:
(1) before the truncation, we will get the profile for the main process
(2) after the truncation, and before write-out the profile, we will get
0 size profile.
(3) after the merged write, we get merged profile.
This patch temporarily suspend the SIGKILL for PR_SET_PDEATHSIG
before profile-write and restore it after the write.
This patch only applies to Linux system.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: xur, llvm-commits
Differential Revision: https://reviews.llvm.org/D29954
llvm-svn: 295364
In D28836, we added a way to tag heap objects and thus provide object types into report. This patch exposes this information into the debugging API.
Differential Revision: https://reviews.llvm.org/D30023
llvm-svn: 295318
Summary:
Add in #ifdef to exclude cpu_model_test on non-X86 and *vfp_test on ARM targets without VFP support.
This is consistent with other target-specific tests that print "Skipped" if not supported.
Reviewers: rengolin, compnerd, asbirlea
Reviewed By: compnerd
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D29882
llvm-svn: 295261
Summary:
There is no guarantee that the tls_init is executed on the static runtime
(/MT).
On windows 7, this unittest is failing.
On windows 10, I believe it's working because of the new CRT.
On ASAN side, it doesn't matter that the hook point is run or not.
It must be run only if there is other tls_initializer that are registered.
Reviewers: rnk, chrisha
Reviewed By: rnk
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D29838
llvm-svn: 295057
Add an #if that excludes the newly added aeabi* tests on non-ARM
platforms. This is consistent with other ARM tests, and aims to make
running builtin tests easier. Lacking a proper infrastructure to run
tests selectively, it is more convenient if we do not have to implement
directory-platform exclusions and can just rely on tests compiling to
no-op on other platforms.
Differential Revision: https://reviews.llvm.org/D29708
llvm-svn: 294438
Add support for weak hooks on Windows, as we do on Linux and Darwin.
As we use the macro: `SANITIZER_INTERFACE_WEAK_DEF()` it was not necessary to
modify the header file: `sanitizer_common_interceptors.h`.
After this diff, many tests were fixed for libFuzzer.
Differential Revision: https://reviews.llvm.org/D29562
llvm-svn: 294409
Summary:
Apparently "test standalone compiler-rt" still requires -ldl and -lrt for
Scudo even with --gc-sections. I am not entirely sure why, so if anybody has
some input, feel free to chime in.
In the meantime, add again those two to fix the test.
Reviewers: kcc, alekseyshl
Reviewed By: kcc
Subscribers: Hahnfeld, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D29527
llvm-svn: 294199
Summary:
The assumption __sanitizer_get_heap_size() == 0 (introduced in D29341) at the
start of a program appears to be incorrect on some ARM machines
(SizeClassAllocator32).
This should fix the test while I investigate the issue.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D29516
llvm-svn: 294056
Summary:
The local and global quarantine sizes were not offering a distinction for
32-bit and 64-bit platforms. This is addressed with lower values for 32-bit.
When writing additional tests for the quarantine, it was discovered that when
calling some of the allocator interface function prior to any allocation
operation having occured, the test would crash due to the allocator not being
initialized. This was addressed by making sure the allocator is initialized
for those scenarios.
Relevant tests were added in interface.cpp and quarantine.cpp.
Last change being the removal of the extraneous link dependencies for the
tests thanks to rL293220, anf the addition of the gc-sections linker flag.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29341
llvm-svn: 294037
This test relies on sanitizer common interceptor to pick the oldest version of
sem_init function from Glibc. But LSan actually doesn't intercept sem_init, thus
the new implementation is called that causes test failure. Disable it for LSan x86,
the proper fix would require to check Glibc version at runtime and adjust
GET_SEM_VALUE(V) accordingly.
llvm-svn: 294001
In this diff I update the code for asan on Windows, so we can intercept
SetUnhandledExceptionFilter and catch some exceptions depending on the result of
IsHandledDeadlyException() (which depends on asan flags).
This way we have the same behavior on Windows and Posix systems.
On Posix, we intercept signal and sigaction, so user's code can only register
signal handlers for signals that are not handled by asan.
After this diff, the same happens on Windows, user's code can only register
exception handlers for exceptions that are not handled by asan.
Differential Revision: https://reviews.llvm.org/D29463
llvm-svn: 293957
This test fails consistently on Ubuntu 16.xx powerpc64 LE systems.
The cause is being investigated and in the meantime disable it so
the buildbots can run cleanly.
llvm-svn: 293939
This patch allows a non-instrumented library to call into TSan runtime, and tell us about "readonly" and "modifying" accesses to an arbitrary "object" and provide the caller and tag (type of object). This allows TSan to detect violations of API threading contracts where "read-only" methods can be called simulatenously from multiple threads, while modifying methods must be exclusive.
Differential Revision: https://reviews.llvm.org/D28836
llvm-svn: 293885
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
We ignore `__ubsan_handle_dynamic_type_cache_miss*` symbols when
`SANITIZER_CAN_USE_CXXABI` is true. Because they are included in the
library but they are not included in the interface lists.
llvm-svn: 293711
The test was failing because we export the functions: "__sanitizer_mz*" but they
are not included in the general interface lists.
Also, weak undefined symbols are tagged with U by `nm -g` on Darwin.
Differential Revision: https://reviews.llvm.org/D29345
llvm-svn: 293710
Add a new auxiliary file to each sanitizer: sanitizer_interface.inc, listing all
the functions exported, with the macros: INTERFACE_FUNCTION() and
INTERFACE_WEAK_FUNCTION().
So, when we need to define or repeat a procedure for each function in the
sanitizer's interface, we can define the macros and include that header.
In particular, these files are needed for Windows, in the nexts commits.
Also, this files could replace the existing files: weak_symbols.txt for Apple.
Instead of reading weak_symbols.txt to get the list of weak symbols, we could
read the file sanitizer_interface.inc and consider all the symbols included with
the macro INTERFACE_WEAK_FUNCTION(Name).
In this commit, I only include these files to the sanitizers that work on
Windows. We could do the same for the rest of the sanitizers when needed.
I updated tests for: Linux, Darwin and Windows. If a new function is exported
but is not present in the interface list, the tests
"interface_symbols_[darwin|windows|linux].c" fail.
Also, I remove the comments: "/* OPTIONAL */" which are not required any more,
because we use the macro: INTERFACE_WEAK_FUNCTION() for weak functions.
Differential Revision: https://reviews.llvm.org/D29148
llvm-svn: 293682
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
Summary:
in aeabi_ldivmod and uldivmod, using r6 instead of r12 as the temp reg due to limitation of Thumb1 ISA.
Now, all EABI sources are Thumb1 compatible.
Also added test cases by reusing the test cases from divmodsi4_test.c, udivmodsi4_test and udivmoddi4_test.c
Reviewers: rengolin, compnerd
Reviewed By: rengolin
Subscribers: javed.absar, aemerson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29226
llvm-svn: 293527
Add "OPTIONAL" comment to declaration of weak function in the internal
interface. This fix the tests `interface_symbols_linux.c` and
`interface_symbols_darwin.c` which were failing after r293423.
llvm-svn: 293442
In this diff, I define a general macro for defining weak functions
with a default implementation: "SANITIZER_INTERFACE_WEAK_DEF()".
This way, we simplify the implementation for different platforms.
For example, we cannot define weak functions on Windows, but we can
use linker pragmas to create an alias to a default implementation.
All of these implementation details are hidden in the new macro.
Also, as I modify the name for exported weak symbols on Windows, I
needed to temporarily disable "dll_host" test for asan, which checks
the list of functions included in asan_win_dll_thunk.
Differential Revision: https://reviews.llvm.org/D28596
llvm-svn: 293419
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
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
Currently, os_id of the main thread contains the PID instead of a thread ID. Let's fix this.
Differential Revision: https://reviews.llvm.org/D29106
llvm-svn: 293201
Summary:
Adding ARM64 as a supported architecture for Scudo.
The random shuffle is not yet supported for SizeClassAllocator32, which is used
by the AArch64 allocator, so disable the associated test for now.
Reviewers: kcc, alekseyshl, rengolin
Reviewed By: rengolin
Subscribers: aemerson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28960
llvm-svn: 293068
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
TSan recently got the "ignore_noninstrumented_modules" flag, which disables tracking of read and writes that come from noninstrumented modules (via interceptors). This is a way of suppressing false positives coming from system libraries and other noninstrumented code. This patch turns this on by default on Darwin, where it's supposed to replace the previous solution, "ignore_interceptors_accesses", which disables tracking in *all* interceptors. The new approach should re-enable TSan's ability to find races via interceptors on Darwin.
Differential Revision: https://reviews.llvm.org/D29041
llvm-svn: 292981
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
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
This fix a bug, when calling InternalGetProcAddress() for an executable that
doesn't export any symbol. So the table is empty.
If we don't check for this condition, the program fails with Error 0xc0000142.
Also, I add a regression test for Windows.
Differential Revision: https://reviews.llvm.org/D28502
llvm-svn: 292747
Fix the logic used to calculate page boundaries in clear_cache_test to
use correct masks -- e.g. -4096 rather than -4095. The latter gives
incorrect result since:
-4095 -> 0xfffff001
-4096 -> 0xfffff000 (== ~4095)
The issue went unnoticed so far because the array alignment caused
the last bit not to be set. However, on 32-bit x86 no such alignment is
enforced and the wrong page address caused the test to fail.
Furthermore, obtain the page size from the system instead of hardcoding
4096.
Differential Revision: https://reviews.llvm.org/D28849
llvm-svn: 292729
Summary:
In an effort to getting rid of dependencies to external libraries, we are
replacing atomic PackedHeader use of std::atomic with Sanitizer's
atomic_uint64_t, which allows us to avoid -latomic.
Reviewers: kcc, phosek, alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28864
llvm-svn: 292630
Running lit tests and unit tests of ASan and TSan on macOS has very bad performance when running with a high number of threads. This is caused by xnu (the macOS kernel), which currently doesn't handle mapping and unmapping of sanitizer shadow regions (reserved VM which are several terabytes large) very well. The situation is so bad that increasing the number of threads actually makes the total testing time larger. The macOS buildbots are affected by this. Note that we can't easily limit the number of sanitizer testing threads without affecting the rest of the tests.
This patch adds a special "group" into lit, and limits the number of concurrently running tests in this group. This helps solve the contention problem, while still allowing other tests to run in full, that means running lit with -j8 will still with 8 threads, and parallelism is only limited in sanitizer tests.
Differential Revision: https://reviews.llvm.org/D28420
llvm-svn: 292549
Summary:
There are cases when thread local quarantine drains almost empty
quarantine batches into the global quarantine. The current approach leaves
them almost empty, which might create a huge memory overhead (each batch
is 4K/8K, depends on bitness).
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28068
llvm-svn: 292525
Summary:
Testing of XRay was occasionally disabled on 32-bit Arm targets (someone assumed that XRay was supported on 64-bit targets only). This patch should fix that problem. Also here the instruction&data cache incoherency problem is fixed, because it may be causing a test to fail.
This patch is one of a series: see also
- https://reviews.llvm.org/D28624
Reviewers: dberris, rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown
Differential Revision: https://reviews.llvm.org/D28623
llvm-svn: 292517
This reverts commit r292211, as it broke the Thumb buldbot with:
clang-5.0: error: the clang compiler does not support '-fxray-instrument
on thumbv7-unknown-linux-gnueabihf'
llvm-svn: 292356
Remove the failing tests for __fixunssfdi() and __fixunsdfdi() that
relied on undefined (and most likely obsolete in terms of compiler-rt
implementation behavior).
Both tests presumed that 0x1.p+64 would be converted to
0xFFFFFFFFFFFFFFFFLL, that is the largest value in uint64 range.
However, the C/C++ standards do not specify the behavior for converting
a floating-point value to an integer of smaller range, and in this case
both libgcc and compiler-rt implementations return 0 instead.
Since the current behavior is correct with regards to standards
and there is no good way of expressing 0xFFFFFFFFFFFFFFFFLL in single-
or double-precision float, I've removed the failing test altogether.
Differential Revision: https://reviews.llvm.org/D28146
llvm-svn: 292257
Running lit tests and unit tests of ASan and TSan on macOS has very bad performance when running with a high number of threads. This is caused by xnu (the macOS kernel), which currently doesn't handle mapping and unmapping of sanitizer shadow regions (reserved VM which are several terabytes large) very well. The situation is so bad that increasing the number of threads actually makes the total testing time larger. The macOS buildbots are affected by this. Note that we can't easily limit the number of sanitizer testing threads without affecting the rest of the tests.
This patch adds a special "group" into lit, and limits the number of concurrently running tests in this group. This helps solve the contention problem, while still allowing other tests to run in full, that means running lit with -j8 will still with 8 threads, and parallelism is only limited in sanitizer tests.
Differential Revision: https://reviews.llvm.org/D28420
llvm-svn: 292232
Summary:
Testing of XRay was occasionally disabled on 32-bit Arm targets (someone assumed that XRay was supported on 64-bit targets only). This patch should fix that problem. Also here the instruction&data cache incoherency problem is fixed, because it may be causing a test to fail.
This patch is one of a series: see also
- https://reviews.llvm.org/D28624
Reviewers: dberris, rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown
Differential Revision: https://reviews.llvm.org/D28623
llvm-svn: 292211
Summary:
Bypass quarantine altogether when quarantine size is set ot zero.
Also, relax atomic load/store of quarantine parameters, the
release/acquire semantics is an overkill here.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D28586
llvm-svn: 291791
Summary:
Repoisoning just the minimal redzones might leave an unpoisoned
gap of the size of the actual redzone minus minimal redzone size.
After ASan activation the actual redzone might be bigger than the minimal
size and ASan allocator assumes that the chunk returned by the common
allocator is either entirely poisoned or entirely not poisoned (it's too
expensive to check the entire chunk or always poison one).
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28577
llvm-svn: 291714
On Darwin, we currently use 'ignore_interceptors_accesses', which is a heavy-weight solution that simply turns of race detection in all interceptors. This was done to suppress false positives coming from system libraries (non-instrumented code), but it also silences a lot of real races. This patch implements an alternative approach that should allow us to enable interceptors and report races coming from them, but only if they are called directly from instrumented code.
The patch matches the caller PC in each interceptors. For non-instrumented code, we call ThreadIgnoreBegin.
The assumption here is that the number of instrumented modules is low. Most likely there's only one (the instrumented main executable) and all the other modules are system libraries (non-instrumented).
Differential Revision: https://reviews.llvm.org/D28264
llvm-svn: 291631
Summary: This patch attempts to fix test patching-unpatching.cc . The new code flushes the instruction cache after modifying the program at runtime.
Reviewers: dberris, rengolin, pelikan, rovka
Subscribers: rovka, llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D27996
llvm-svn: 291568
Revert "ASAN activate/deactive controls thread_local_quarantine_size_kb option."
Revert "Bypass quarantine when quarantine size is set ot zero."
Revert "ASAN activate/deactive controls thread_local_quarantine_size_kb option."
One of these commits broke some of the ARM / AArch64 buildbots:
TEST 'AddressSanitizer-aarch64-linux :: TestCases/Posix/start-deactivated.cc' FAILED
Command Output (stderr):
--
/home/buildslave/buildslave/clang-cmake-aarch64-42vma/llvm/projects/compiler-rt/test/asan/TestCases/Posix/start-deactivated.cc:85:12: error: expected string not found in input
// CHECK: WARNING: AddressSanitizer failed to allocate 0xfff{{.*}} bytes
^
<stdin>:1:1: note: scanning from here
start-deactivated.cc.tmp: /home/buildslave/buildslave/clang-cmake-aarch64-42vma/llvm/projects/compiler-rt/test/asan/TestCases/Posix/start-deactivated.cc:40: void test_malloc_shadow(char *, size_t, bool): Assertion `(char *)__asan_region_is_poisoned(p - 1, sz + 1) == (expect_redzones ? p - 1 : nullptr)' failed.
^
<stdin>:2:1: note: possible intended match here
Error: Aborted (core dumped)
^
llvm-svn: 291560
Summary:
The build system was inconsistent in its naming conventions for
link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS,
for consistency with cmake's LINK_FLAGS property.
This patch should make it easier to search the source code for
uses of link flags, as well as providing the benefit of improved
style and consistency.
Reviewers: compnerd, beanz
Subscribers: kubabrecka, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28506
llvm-svn: 291539
Tests need to output everything into a single stream, or FileCheck is sometimes confused (buffering can cause stdout/stderr to be interleaved randomly).
llvm-svn: 291339
This patch starts passing architecture information about a module to llvm-symbolizer and into text reports. This fixes the longstanding x86_64/x86_64h mismatch issue on Darwin.
Differential Revision: https://reviews.llvm.org/D27390
llvm-svn: 291287
This patch add a new sanitizer flag, print_module_map, which enables printing a module map when the process exits, or after each report (for TSan). The output format is very similar to what Crash Reporter produces on Darwin (e.g. the format of module UUIDs). This enables users to use the existing symbol servers to offline symbolicate and aggregate reports.
Differential Revision: https://reviews.llvm.org/D27400
llvm-svn: 291277
Implement the missing __floattitf() and __floatuntitf() functions, to
convert 128-bit (unsigned) integers to quad-precision floating-point
types. This is needed e.g. on AArch64 where 'long double' is
a quad-precision type.
The code is based on the existing code for __floattixf()
and __floatuntixf(), updated to account for different bit field lengths
of quad-precision float. The tests are also copied, with the rounding
tests adjusted for longer significand.
Differential Revision: https://reviews.llvm.org/D27898
llvm-svn: 291259
The reason they should have failed: absent sancov.
In this test (vs the trace_pc_guard test) sancov is not
yet called (not implemented).
llvm-svn: 291080
Summary:
At this point SANCOV_OPTIONS are not functional but it is our intent
to move here sanitizer coverage flags from various sanitizers _OPTIONS.
Reviewers: kcc
Subscribers: kubabrecka, mgorny
Differential Revision: https://reviews.llvm.org/D28311
llvm-svn: 291068
Summary:
If you decide to recompile parts of your Linux distro with XRay, it may
be useful to know which trace belongs to which binary. While there, get
rid of the incorrect strncat() usage; it always returns a pointer to the
start which makes that if() always true. Replace with snprintf which is
bounded so that enough from both strings fits nicely.
Reviewers: dberris
Subscribers: danalbert, srhines, kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27912
llvm-svn: 290861
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 290852
Summary:
Reduce RSS size treshold in the unit test to accomodate for the smaller
ASAN quarantine size on Android (see D27873).
Reviewers: eugenis
Patch by Alex Shlyapnikov.
Subscribers: danalbert, kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28132
llvm-svn: 290643
Use some new substitutions to avoid duplicating the tests for just
dropped flags. -fPIC/-fPIE/-fpic/-fpie do not make sense on Windows as
they can cause ELF-style PIC. Substitute away the flag on Windows.
This should repair the windows buildbots.
llvm-svn: 290571
Summary: This patch attempts to fix test patching-unpatching.cc . The new code flushes the instruction cache after modifying the program at runtime.
Reviewers: dberris, rengolin
Subscribers: llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D27996
llvm-svn: 290452
Summary: The macro was introduced with D26929, use it in Scudo as well.
Reviewers: kcc, alekseyshl, kubabrecka
Subscribers: llvm-commits, danalbert, srhines, mgorny
Differential Revision: https://reviews.llvm.org/D28066
llvm-svn: 290439
Fix missing "int_lib.h" includes in ARM negdf2vfp and subdf3vfp tests.
Additionally, extend the __arm__ guard to cover the builtin definition
in the former. This is mostly intended to prevent build failures
and allow those tests to be properly skipped on other targets.
Differential Revision: https://reviews.llvm.org/D28078
llvm-svn: 290422
Summary: Make thread local quarantine size an option so it can be turned off to save memory.
Reviewers: eugenis
Patch by Alex Shlyapnikov.
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28027
llvm-svn: 290373
Summary: This patch attempts to fix test patching-unpatching.cc . The new code flushes the instruction cache after modifying the program at runtime.
Reviewers: dberris, rengolin
Subscribers: llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D27996
llvm-svn: 290354
Summary:
With the previous modifications, the code works on ARM32. The random shuffle
test is unsupported on 32-bit platforms for the moment and being marked as
such. There is no hardware support for the checksum computation yet, this will
come at a later point.
Reviewers: kcc, alekseyshl
Subscribers: llvm-commits, aemerson, rengolin, mgorny
Differential Revision: https://reviews.llvm.org/D27957
llvm-svn: 290201
In ASan, we have __asan_locate_address and __asan_get_alloc_stack, which is used in LLDB/Xcode to show the allocation backtrace for a heap memory object. This patch implements the same for TSan.
Differential Revision: https://reviews.llvm.org/D27656
llvm-svn: 290119
We already have an interceptor for __shared_weak_count::__release_shared, this patch handles __shared_count::__release_shared in the same way. This should get rid of TSan false positives when using std::future.
Differential Revision: https://reviews.llvm.org/D27797
llvm-svn: 289831
Objects may move during the garbage collection, and JVM needs
to notify ThreadAnalyzer about that. The new function
__tsan_java_find eliminates the need to maintain these
objects both in ThreadAnalyzer and JVM.
Author: Alexander Smundak (asmundak)
Reviewed in https://reviews.llvm.org/D27720
llvm-svn: 289682
Summary:
Now that we are not rounding up the sizes passed to the secondary allocator,
the memalign test could run out of aligned addresses to return for larger
alignments. We now reduce the size of the quarantine for that test, and
allocate less chunks for the larger alignments.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27760
llvm-svn: 289665
This doesn't work at all on big-endian systems, even just reading in the
magic bytes in the binary .sancov file header gets byte order wrong.
llvm-svn: 289539
fatal error: error in backend: Global variable '__sancov_gen_' has an
invalid section specifier '__sancov_guards': mach-o section specifier
requires a segment and section separated by a comma.
llvm-svn: 289507
This target doesn't currently do anything, but it is required by
the runtimes build.
Differential Revision: https://reviews.llvm.org/D27640
llvm-svn: 289420
We currently have a interceptor for malloc_create_zone, which returns a new zone that redirects all the zone requests to our sanitizer zone. However, calling malloc_destroy_zone on that zone will cause libmalloc to print out some warning messages, because the zone is not registered in the list of zones. This patch handles this and adds a testcase for that.
Differential Revision: https://reviews.llvm.org/D27083
llvm-svn: 289375
Summary: For platforms which support slow unwinder only, we restrict the store context size to 1, basically only storing the current pc. We do this because the slow unwinder which is based on libunwind is not async signal safe and causes random freezes in forking applications as well as in signal handlers.
Reviewed by eugenis.
Differential: D23107
llvm-svn: 289027
Summary:
The test `XRay-aarch64-linux::patching-unpatching.cc` sometimes passes, sometimes fails on buildbots.
This patch disables test `patching-unpatching.cc` for AArch64 targets.
Reviewers: rengolin, dberris
Subscribers: llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D27528
llvm-svn: 288988
Summary: Old bash release (3.2) on SLES11 chokes on new redirection shortcut.
Patch by Brian Cain.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D27443
llvm-svn: 288854
As constructed before this patch, in case we run into case where we
don't actually build the XRay library, we really ought to not be adding
the unit test runs. This should fix the bootstrap build failures.
This is a follow-up further to D26232.
llvm-svn: 288788
The bootstrap buildbot complains about not being able to find the
unittests for XRay, when the conditionals to include or not include
tests and unit tests don't match.
This is a follow-up to D26232.
llvm-svn: 288786
Before this change we would add the unit tests potentially even if we
don't actually include the unit tests.
This is a follow-up on D26232.
llvm-svn: 288785
This implements a simple buffer queue to manage a pre-allocated queue of
fixed-sized buffers to hold XRay records. We need this to support
Flight Data Recorder (FDR) mode. We also implement this as a sub-library
first to allow for development before actually using it in an
implementation.
Some important properties of the buffer queue:
- Thread-safe enqueueing/dequeueing of fixed-size buffers.
- Pre-allocation of buffers at construction.
This is a re-roll of the previous attempt to submit, because it caused
failures in arm and aarch64.
Reviewers: majnemer, echristo, rSerge
Subscribers: tberghammer, danalbert, srhines, modocache, mehdi_amini, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26232
llvm-svn: 288775
Summary: The function computes full module name and coverts pc into offset.
Reviewers: kcc
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D26820
llvm-svn: 288711
Summary:
Unfortunately, there is no way to emit an llvm masked load/store in
clang without optimizations, and AVX enabled. Unsure how we should go
about making sure this test only runs if it's possible to execute AVX
code.
Reviewers: kcc, RKSimon, pgousseau
Subscribers: kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D26506
llvm-svn: 288504
Summary:
This update introduces i386 support for the Scudo Hardened Allocator, and
offers software alternatives for functions that used to require hardware
specific instruction sets. This should make porting to new architectures
easier.
Among the changes:
- The chunk header has been changed to accomodate the size limitations
encountered on 32-bit architectures. We now fit everything in 64-bit. This
was achieved by storing the amount of unused bytes in an allocation rather
than the size itself, as one can be deduced from the other with the help
of the GetActuallyAllocatedSize function. As it turns out, this header can
be used for both 64 and 32 bit, and as such we dropped the requirement for
the 128-bit compare and exchange instruction support (cmpxchg16b).
- Add 32-bit support for the checksum and the PRNG functions: if the SSE 4.2
instruction set is supported, use the 32-bit CRC32 instruction, and in the
XorShift128, use a 32-bit based state instead of 64-bit.
- Add software support for CRC32: if SSE 4.2 is not supported, fallback on a
software implementation.
- Modify tests that were not 32-bit compliant, and expand them to cover more
allocation and alignment sizes. The random shuffle test has been deactivated
for linux-i386 & linux-i686 as the 32-bit sanitizer allocator doesn't
currently randomize chunks.
Reviewers: alekseyshl, kcc
Subscribers: filcab, llvm-commits, tberghammer, danalbert, srhines, mgorny, modocache
Differential Revision: https://reviews.llvm.org/D26358
llvm-svn: 288255
The Clang driver on macOS decides the deployment target based on various things, like your host OS version, the SDK version and some environment variables, which makes lit tests pass or fail based on your environment. Let's make sure we run all lit tests with `-mmacosx-version-min=${SANITIZER_MIN_OSX_VERSION}` (10.9 unless overriden).
Differential Revision: https://reviews.llvm.org/D26929
llvm-svn: 288186
Summary:
Unfortunately, there is no way to emit an llvm masked load/store in
clang without optimizations, and AVX enabled. Unsure how we should go
about making sure this test only runs if it's possible to execute AVX
code.
Reviewers: kcc, RKSimon, pgousseau
Subscribers: kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D26506
llvm-svn: 288162
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
See D19555 for rationale. As it turns out, this treatment is also necessary
for scanf/printf.
Differential Revision: https://reviews.llvm.org/D27118
llvm-svn: 288064
The lit expansion of "%deflake " (notice the space after) expands in a way that the space is removed, this fixes that.
Differential Revision: https://reviews.llvm.org/D27139
llvm-svn: 287989
Handling SIGILL on Darwin works fine, so let's just make this feature work and re-enable the ill.cc testcase.
Differential Revision: https://reviews.llvm.org/D27141
llvm-svn: 287959
This patch prints out all CPU registers after a SIGSEGV. These are available in the signal handler context. Only implemented for Darwin. Can be turned off with the dump_registers flag.
Differential Revision: https://reviews.llvm.org/D11365
llvm-svn: 287957
Summary:
This implements a simple buffer queue to manage a pre-allocated queue of
fixed-sized buffers to hold XRay records. We need this to support
Flight Data Recorder (FDR) mode. We also implement this as a sub-library
first to allow for development before actually using it in an
implementation.
Some important properties of the buffer queue:
- Thread-safe enqueueing/dequeueing of fixed-size buffers.
- Pre-allocation of buffers at construction.
Reviewers: majnemer, rSerge, echristo
Subscribers: mehdi_amini, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26232
llvm-svn: 287910
GCD queues can be suspended and resumed with dispatch_suspend and dispatch_resume. We need to add synchronization between the call to dispatch_resume and any subsequent executions of blocks in the queue that was resumed. We already have an Acquire(q) before the block executes, so this patch just adds the Release(q) in an interceptor of dispatch_resume.
Differential Revision: https://reviews.llvm.org/D27112
llvm-svn: 287902
/proc/self/maps can't be read atomically, this leads to episodic
crashes in libignore as it thinks that a module is loaded twice.
See the new test for an example.
dl_iterate_phdr does not have this problem.
Switch libignore to dl_iterate_phdr.
llvm-svn: 287632
The ODR detection in initialization-bug.cc now works on Darwin (due to the recently enabled "live globals" on-by-default), but only if the deployment target is 10.11 or higher. Let's adjust the testcases.
Differential Revision: https://reviews.llvm.org/D26927
llvm-svn: 287581
Summary:
Turns out that in the case of -fsanitize=null and a virtual call,
the type check was generated *after* reading from vtable, which
causes a non-interpretable segfault. The check has been moved up
in https://reviews.llvm.org/D26559 and this CL adds a test for this case.
Reviewers: pcc
Subscribers: cfe-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26560
llvm-svn: 287578
We're seeying these errors with GCC and Clang on different systems, while
some other identical OSs on different boards fail. Like many other ASAN
tests, there seem to be no easy way to investigate this other than someone
familiar with the sanitizer code and the ARM libraries.
At least, for now, we'll silence the bots. I'll create a bugzilla entry.
llvm-svn: 287464
Summary:
The expectation is that new instrumented code will add global variable
metadata to the .ASAN$GL section, and we will use this new code to
iterate over it.
This technique seems to break when using incremental linking, which
seems to align every global to a 256 byte boundary. Presumably this is
so that it can incrementally cope with global changing size. Clang
already passes -incremental:no as a linker flag when you invoke it to do
the link step.
The two tests added for this feature will fail until the LLVM
instrumentation change in D26770 lands, so they are marked XFAIL for
now.
Reviewers: pcc, kcc, mehdi_amini, kubabrecka
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D26771
llvm-svn: 287246
This adds support for TSan C++ exception handling, where we need to add extra calls to __tsan_func_exit when a function is exitted via exception mechanisms. Otherwise the shadow stack gets corrupted (leaked). This patch moves and enhances the existing implementation of EscapeEnumerator that finds all possible function exit points, and adds extra EH cleanup blocks where needed.
Differential Revision: https://reviews.llvm.org/D26177
llvm-svn: 286894
Summary:
ASan needs to initialize before ucrtbase.dll so that it can intercept
all of its heap allocations. New versions of dbghelp.dll depend on
ucrtbase.dll, which means both of those DLLs will initialize before the
dynamic ASan runtime. By lazily loading dbghelp.dll with LoadLibrary, we
avoid the issue.
Eventually, I would like to remove our dbghelp.dll dependency in favor
of always using llvm-symbolizer.exe, but this seems like an acceptable
interim solution.
Fixes PR30903
Reviewers: etienneb
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26473
llvm-svn: 286848
This patch replaces fprintf with print_address function in LSAN
tests. This is necessary because of different printing of pointers
in fprintf and sanitizer's print function.
Differential Revision: https://reviews.llvm.org/D26084.
llvm-svn: 286816
Summary:
In non-strict mode we will check memory access for both strings from beginning
to either:
1. 0-char
2. size
3. different chars
In strict mode we will check from beginning to either:
1. 0-char
2. size
Previously in strict mode we always checked up to the 0-char.
Reviewers: kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26574
llvm-svn: 286708
Summary: Unit tests for the new clang flags.
Reviewers: eugenis, dvyukov
Subscribers: kubabrecka, llvm-commits
Patch by Alex Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D26462
llvm-svn: 286670
Changed the kernel sigaction structure in test syscalls_sigaction.cc for MIPS according to the structure defined in kernel.
Reviewed by eugenis.
Differential: https://reviews.llvm.org/D25814
llvm-svn: 286583
I'm not sure why is it there, but it is breaking tests on Android N
because of unexpected linker output about an empty LD_LIBRARY_PATH
entry.
llvm-svn: 286321
Summary:
User applications may register hooks in the .CRT$XL* callback list,
which is called very early by the loader. This is very common in
Chromium:
https://cs.chromium.org/search/?q=CRT.XL&sq=package:chromium&type=cs
This has flown under the radar for a long time because the loader
appears to catch exceptions originating from these callbacks. It's a
real problem when you're debugging an asan application, though, since it
makes the program crash early.
The solution is to add our own callback to this list, and sort it very
early in the list like we do elsewhere. Also add a test with such an
instrumented callback, and test that it gets called with asan.
Reviewers: etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26404
llvm-svn: 286290
Atomic stores terminate release sequences on the atomic variable,
and must use ReleaseStore primitive instead of Release.
This was broken in r192355 during a refactoring.
Restore correct behavior and add a test.
llvm-svn: 286211
Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. The TSan instrumentation pass however tries to emit inttoptr, which is incorrect, we should use a bitcast here. Anyway, IRBuilder already has a convenient helper function for this.
Differential Revision: https://reviews.llvm.org/D26266
llvm-svn: 286136
Only tests using %clang_cl_asan were using the dynamic CRT before this.
The unit tests and lit tests using %clangxx_asan were using the static
CRT. Many cross-platform tests fail with the dynamic CRT, so I had to
add win32-(static|dynamic)-asan lit features.
Also deletes some redundant tests in TestCases/Windows that started
failing with this switch.
llvm-svn: 285821
Apparently, the std_shared_ptr.cc testcase works fine on Darwin, even without the instrumented libcxx. Let's enable it.
Differential Revision: https://reviews.llvm.org/D26162
llvm-svn: 285634
On Darwin, simple C null-terminated constant strings normally end up in the __TEXT,__cstring section of the resulting Mach-O binary. When instrumented with ASan, these strings are transformed in a way that they cannot be in __cstring (the linker unifies the content of this section and strips extra NUL bytes, which would break instrumentation), and are put into a generic __const section. This breaks some of the tools that we have: Some tools need to scan all C null-terminated strings in Mach-O binaries, and scanning all the contents of __const has a large performance penalty. This patch instead introduces a special section, __asan_cstring which will now hold the instrumented null-terminated strings.
Differential Revision: https://reviews.llvm.org/D25026
llvm-svn: 285620
GCD (libdispatch) has a concept of “target queues”: Each queue has either an implicit or explicit target queue, where the task is handed over to when it’s time to execute it. For example, a concurrent queue can have a serial target queue (effectively making the first queue serial), or multiple queues can have the same serial target queue (which means tasks in all the queues are mutually excluded). Thus we need to acquire-release semantics on the full “chain” of target queues.
This patch changes the way we Acquire() and Release() when executing tasks in queues. Now we’ll walk the chain of target queues and synchronize on each queue that is serial (or when dealing with a barrier block). This should avoid false positives when using dispatch_set_target_queue().
Differential Revision: https://reviews.llvm.org/D25835
llvm-svn: 285613
ASan dead-strip support relies on a linker option that only exists
in 10.11 and later, so the LLVM instrumentation checks for the deployment
target. This test does not pass when clang is built to choose lower
deployment target by default but runs on newer host.
(Note, the REQUIRES: osx-ld64-live_support clause only checks the host
and not the target OS.)
Differential Revision: https://reviews.llvm.org/D26107
llvm-svn: 285482
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
Summary:
In order to support 32-bit platforms, we have to make some adjustments in
multiple locations, one of them being the Scudo chunk header. For it to fit on
64 bits (as a reminder, on x64 it's 128 bits), I had to crunch the space taken
by some of the fields. In order to keep the offset field small, the secondary
allocator was changed to accomodate aligned allocations for larger alignments,
hence making the offset constant for chunks serviced by it.
The resulting header candidate has been added, and further modifications to
allow 32-bit support will follow.
Another notable change is the addition of MaybeStartBackgroudThread() to allow
release of the memory to the OS.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25688
llvm-svn: 285209
The test contains a switch statement in which two of the cases are
tail-merged, with the call to __ubsan_handle_dynamic_type_cache_miss_abort
in the common tail. When tail-merging occurs, the debug location of the
tail is randomly taken from one of the merge inputs. Luckily for the test,
the expected line number in the check is the one which is chosen by the
tail-merge. However, if the switch cases are re-ordered the test will
fail.
This patch disables tail-merge, making the test resilient to changes
in tail-merge, and unblocking review D25742. It does not change the
semantics of the test.
llvm-svn: 285208
Darwin's implementation of strstr seems to trigger slightly different failure
modes from Linux since it calls strncmp. All messages seem about equally useful
and correct, so I relaxed the tests so Darwin can pass.
llvm-svn: 285004
This patch replaces fprintf with print_address function
in LSAN tests. This is necessary because of different
printing of pointers in fprintf and sanitizer's print
function. Differential Revision: https://reviews.llvm.org/D25270.
llvm-svn: 284722
This makes __llvm_profile_set_filename() work across dylib boundaries on
Darwin.
This functionality was originally meant to work on all platforms, but
was moved to a Linux-only directory with r272404. The root cause of the
test failure on Darwin was that lprofCurFilename was not marked weak.
Each dylib maintained its own copy of the variable due to the two-level
namespace.
Tested with check-profile (on Darwin). I don't expect this to regress
other platforms.
Differential Revision: https://reviews.llvm.org/D25707
llvm-svn: 284440
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
Reapply 282061.
One of the tests relying on sem_t's layout gets the wrong value for versions of
glibc newer than 2.21 on platforms that don't have 64-bit atomics (e.g. ARM).
This commit fixes the test to work with:
* versions of glibc >= 2.21 on platforms with 64-bit atomics: unchanged
* versions of glibc >= 2.21 on platforms without 64-bit atomics: the semaphore
value is shifted by SEM_VALUE_SHIFT (which is set to 1 in glibc's internal
headers)
* versions of glibc < 2.21: unchanged
The logic is complicated a bit by the fact that the sanitizers always pick the
oldest version of the symbol available in glibc, which creates discrepancies
between old platforms which contain several versions od the sem_init symbol, and
newer platforms which contain only one.
See the glibc 2.23 sources:
* sysdeps/nptl/internaltypes.h (struct new_sem for glibc >= 2.21 and
struct old_sem for glibc < 2.21)
* nptl/sem_getvalue.c
This was uncovered on one of the new buildbots that we are trying to move to
production.
Differential Revision: https://reviews.llvm.org/D24766
llvm-svn: 283299
Summary:
s/CHECK_LT/CHECK_LE/ in the secondary allocator, as under certain circumstances
Ptr + Size can be equal to MapEnd. This edge case was not found by the current
tests, so those were extended to be able to catch that.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25101
llvm-svn: 282913
Summary:
This test is broken on wndows 64-bit.
The interception library is not able to hook on the memchr functions.
Snippet of the function that is not hookable:
```
--- No source file -------------------------------------------------------------
000007FEFA1A18CD CC int 3
000007FEFA1A18CE CC int 3
000007FEFA1A18CF CC int 3
--- f:\dd\vctools\crt\vcruntime\src\string\amd64_arm_arm64\memchr.c ------------
while ( cnt && (*(unsigned char *)buf != (unsigned char)chr) ) {
000007FEFA1A18D0 4D 85 C0 test r8,r8
000007FEFA1A18D3 74 0D je memchr+12h (07FEFA1A18E2h)
000007FEFA1A18D5 38 11 cmp byte ptr [rcx],dl
000007FEFA1A18D7 74 09 je memchr+12h (07FEFA1A18E2h)
buf = (unsigned char *)buf + 1;
000007FEFA1A18D9 48 FF C1 inc rcx
cnt--;
000007FEFA1A18DC 49 83 E8 01 sub r8,1
000007FEFA1A18E0 75 F3 jne memchr+5h (07FEFA1A18D5h)
}
```
Reviewers: rnk
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D25037
llvm-svn: 282860
Summary:
On windows, the memcpy and memmove function can be the same.
This is correcly detected when hooking, but it's not possible
to report the right function name when doing symbolisation.
The same fix was applied for the static asan unittest.
We forgot to apply the fix for the dynamic asan tests.
```
lvm\projects\compiler-rt\test\asan/TestCases/Windows/.svn/text-base/intercept_memcpy.cc.svn-base:// CHECK-NEXT: __asan_{{.*}}mem{{.*}}
```
This patch is fixing this test (win64):
```
ddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
```
Reviewers: rnk, vitalybuka
Subscribers: llvm-commits, kubabrecka, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D25038
llvm-svn: 282859
This patch extends __sanitizer_finish_switch_fiber method to optionally return previous stack base and size.
This solves the problem of coroutines/fibers library not knowing the original stack context from which the library is used. It's incorrect to assume that such context is always the default stack of current thread (e.g. one such library may be used from a fiber/coroutine created by another library). Bulding a separate stack tracking mechanism would not only duplicate AsanThread, but also require each coroutines/fibers library to integrate with it.
Author: Andrii Grynenko (andriigrynenko)
Reviewed in: https://reviews.llvm.org/D24628
llvm-svn: 282582
Profile-aarch64 :: Linux/comdat_rename.test
Profile-aarch64 :: Linux/extern_template.test
Profile-aarch64 :: Linux/instrprof-comdat.test
Profile-aarch64 :: Linux/instrprof-cs.c
The issue is that the created (aarch64) binaries were attempting to run natively
instead of running through %run, which guarantees running in the proper
environment if the compilation was configured correctly.
llvm-svn: 282264
Summary:
The 'asan_preload_test-1.cc' is not working with the i686 architecture.
To repro the error, run on a linux 64-bit:
```
ninja check-asan-dynamic
```
The following error occurs:
```
--
Exit Code: 1
Command Output (stderr):
--
/home/llvm/llvm/projects/compiler-rt/test/asan/TestCases/Linux/asan_preload_test-1.cc:18:12: error: expected string not found in input
// CHECK: AddressSanitizer: heap-buffer-overflow
^
<stdin>:1:1: note: scanning from here
ERROR: ld.so: object 'libclang_rt.asan-i686.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
^
<stdin>:2:10: note: possible intended match here
==25982==AddressSanitizer CHECK failed: /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:736 "((__interception::real_memcpy)) != (0)" (0x0, 0x0)
```
The unittest is running (where %shared_libasan is replaced by libclang_rt.asan-i686.so):
```
// RUN: env LD_PRELOAD=%shared_libasan not %run %t 2>&1 | FileCheck %s
```
But the executable also has a dependancy on libclang_rt.asan-i386.so (added by the clang driver):
```
linux-gate.so.1 => (0xf77cc000)
libclang_rt.asan-i386.so => not found
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf76ba000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7673000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7656000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74a7000)
```
By looking to the clang driver (tools.cpp) we can see that every x86 architecture are mapped to 'i386'.
```
StringRef MyArch;
switch (getToolChain().getArch()) {
case llvm::Triple::arm:
MyArch = "arm";
break;
case llvm::Triple::x86:
MyArch = "i386";
break;
case llvm::Triple::x86_64:
MyArch = "amd64";
break;
default:
llvm_unreachable("Unsupported architecture");
}
```
This patch is implementing the same mapping but in the compiler-rt unittest.
Reviewers: rnk, vitalybuka
Subscribers: aemerson, kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24838
llvm-svn: 282263
4.1+ Linux kernels map pie binaries at 0x55:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90
Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503).
Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb).
This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb.
This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping.
llvm-svn: 282152
For mips assember '#' is the start of comment. We get assembler error messages if # is used in the struct names. Therefore using '$' which works for all architectures.
Differential: D24335
Reviewed by: zhaoqin
llvm-svn: 282142
One of the tests relying on sem_t's layout gets the wrong value for versions of
glibc newer than 2.21 on platforms that don't have 64-bit atomics (e.g. ARM).
This commit fixes the test to work with:
* versions of glibc >= 2.21 on platforms with 64-bit atomics: unchanged
* versions of glibc >= 2.21 on platforms without 64-bit atomics: the semaphore
value is shifted by SEM_VALUE_SHIFT (which is set to 1 in glibc's internal
headers)
* versions of glibc < 2.21: unchanged
See the glibc 2.23 sources:
* sysdeps/nptl/internaltypes.h (struct new_sem for glibc >= 2.21 and
struct old_sem for glibc < 2.21)
* nptl/sem_getvalue.c
This was uncovered on one of the new buildbots that we are trying to move to
production.
Differential Revision: https://reviews.llvm.org/D24766
llvm-svn: 282061
Summary:
GetActuallyAllocatedSize() was not accounting for the last page of the mapping
being a guard page, and was returning the wrong number of actually allocated
bytes, which in turn would mess up with the realloc logic. Current tests didn't
find this as the size exercised was only serviced by the Primary.
Correct the issue by subtracting PageSize, and update the realloc test to
exercise paths in both the Primary and the Secondary.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24787
llvm-svn: 282030
Summary:
The Sanitizer Secondary Allocator was not entirely ideal was Scudo for several
reasons: decent amount of unneeded code, redundant checks already performed by
the front end, unneeded data structures, difficulty to properly protect the
secondary chunks header.
Given that the second allocator is pretty straight forward, Scudo will use its
own, trimming all the unneeded code off of the Sanitizer one. A significant
difference in terms of security is that now each secondary chunk is preceded
and followed by a guard page, thus mitigating overflows into and from the
chunk.
A test was added as well to illustrate the overflow & underflow situations
into the guard pages.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24737
llvm-svn: 281938
Summary:
I need to redu solution, existing is not good enough.
PR28267
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24490
llvm-svn: 281687
The '-asan-use-private-alias’ option (disabled by default) option is currently only enabled for Linux and ELF, but it also works on Darwin and Mach-O. This option also fixes a known problem with LTO on Darwin (https://github.com/google/sanitizers/issues/647). This patch enables the support for Darwin (but still keeps it off by default) and adds the LTO test case.
Differential Revision: https://reviews.llvm.org/D24292
llvm-svn: 281472
It makes the tests extremely slow due to high latency of the test launcher.
The main reason for -j5 was high memory usage with handle_abort=1, which
is now disabled in the test runner.
llvm-svn: 281409
When running with start_deactivated=1 in ASAN_OPTIONS, heap redzones
are not poisoned until the first instrumented module is loaded. This
can cause false negatives even on memory allocated after activation,
because redzones are normally poisoned only once when a new allocator
region is mapped.
This change attempts to fix it by iterating over all existing
allocator chunks and poisoning their redzones.
llvm-svn: 281364
The same thing is already done on Mac. handle_abort slows down tests
significantly because it triggers tombstone collection on Android;
also, it changes failed test outcome from "not-crash" to "crash" (as
in "bin/not --crash").
This change adds handle_abort=0 to asan options on android (test
only!), and also tweaks android_run.py to semi-correctly pass the
crash/no-crash status to the caller.
llvm-svn: 281075
Summary: Merges back both scariness_score_test.cc files, since the Linux-specific version shouldn't be needed any more.
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24347
llvm-svn: 281048
This patch adds a wrapper for call_once, which uses an already-compiled helper __call_once with an atomic release which is invisible to TSan. To avoid false positives, the interceptor performs an explicit atomic release in the callback wrapper.
Differential Revision: https://reviews.llvm.org/D24188
llvm-svn: 280920
Reset the SIGABRT signal handler before calling abort().
Also, change the error message when catching SIGABRT to say "ABRT"
instead of "SEGV".
llvm-svn: 280885
With this patch 10 out of 13 tests are passing.
Following is the list of failing tests:
struct-simple.cpp
workingset-signal-posix.cpp
mmap-shadow-conflict.c
Reviewed by bruening
Differential: D23799
llvm-svn: 280795
Summary:
Only one of the tests in it doesn't work on OS X.
On Windows it seems that everything that is being moved is also
supported.
The abort() test wasn't copied over (original case 22). This is because
it doesn't work on OS X.
Reviewers: kcc, eugenis, vitalybuka
Subscribers: kubabrecka, llvm-commits
llvm-svn: 280469
Another CFG optimisation patch (280364) has broken bad profile tests, and this
is a similar attempt to fix the test without changing the semantics.
llvm-svn: 280373
Commit r280364 has introduced some call-graph optmisations making a profiler
test "fail" due to not expecting the compiler to be "smart", and fold constants
across functions. This commit works around the issue, leaving the origial
semantics intact.
llvm-svn: 280365
The abort() test wasn't copied over (original case 22). This is because
it doesn't work on OS X.
If theres no buildbot problem with this test later today, I will
minimize the Linux version.
llvm-svn: 280361
Summary:
We are going to use store instructions to poison some allocas.
Runtime flag will require branching in instrumented code on every lifetime
intrinsic. We'd like to avoid that.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23967
llvm-svn: 279981
My attempt to disable this test on i386 by adding "UNSUPPORTED: i386-apple"
in r279880 wasn't succesful, so I'm using REQUIRES instead.
llvm-svn: 279916
atos currently doesn't work well when loaded from 32-bit binaries, which
was causing some of the bots to fail. Disable this test until we can
come up with a better fix.
llvm-svn: 279880
Depends on D21612 which implements the building blocks for the compiler-rt
implementation of the XRay runtime. We use a naive in-memory log of fixed-size
entries that get written out to a log file when the buffers are full, and when
the thread exits.
This implementation lays some foundations on to allowing for more complex XRay
records to be written to the log in subsequent changes. It also defines the format
that the function call accounting tool in D21987 will start building upon.
Once D21987 lands, we should be able to start defining more tests using that tool
once the function call accounting tool becomes part of the llvm distribution.
Reviewers: echristo, kcc, rnk, eugenis, majnemer, rSerge
Subscribers: sdardis, rSerge, dberris, tberghammer, danalbert, srhines, majnemer, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D21982
llvm-svn: 279805
This should un-break users that have not re-generated their CMake
configs when they ran it when this was defaulted to OFF. Related to
r277975 post-commit review.
llvm-svn: 279802
This patch adds 48-bits VMA support for msan on aarch64. As current
mappings for aarch64, 48-bit VMA also supports PIE executable. The
48-bits segments only cover the usual PIE/default segments plus some
more segments (262144GB total, 0.39% total VMA). Memory avaliability
can be increase by adding multiple application segments like 39 and
42 mapping (some mappings were added on this patch as well).
Tested on 39 and 48-bit VMA kernels on aarch64.
llvm-svn: 279752
and x86_64h-apple.
Mark the test as UNSUPPORTED to fix a bot that is failing.
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check
The bot is failing because asan_symbolize.py cannot tell whether the
reported address is from an x86_64 slice or an x86_64h slice by the
length of the address alone, so it ends up passing the wrong arch to
atos.
rdar://problem/27907889
llvm-svn: 279614
Durning standalone builds (which includes runtimes builds) we want to create a target named check-compiler-rt. Additionally we also create check-all if it doesn't already exist as a convienence target that depends on check-compiler-rt.
This allows us to generate a single check target that invokes lit for all test suites in the runtimes projects, while avoiding name collision of check-all and not breaking existing workflows.
llvm-svn: 279334
Summary:
test/builtins/Unit/cpu_model_test.c tests the X86 specific builtin `__builtin_cpu_supports`.
It fails if the clang's default target is not X86.
The proposed patch adds an additional requirement for the X86 target to the test, making lit ignore the test if the target is different.
Reviewers: asbirlea
Subscribers: dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D23633
llvm-svn: 279071
Summary:
[[@LINE-30]] only worked because the resulting 3 matches the first character of
30. With the additional blank lines the resulting 5 no longer matches 30.
Reviewers: eugenis
Subscribers: eugenis, llvm-commits
Differential Revision: https://reviews.llvm.org/D23515
llvm-svn: 278715
These tests were recently enabled and have never worked on this builder.
Three tests were sensitive to line number changes:
test/msan/Linux/obstack.cc
test/msan/chained_origin.cc
test/msan/chained_origin_memcpy.cc
and this sensitivity will be addressed in a follow-up patch. Of these,
obstack.cc's sensitivity to line numbers is unexplained since it already uses
[[@LINE]].
llvm-svn: 278671
Summary: Add a test case for __attribute__((no_sanitize("cfi"))) being effective.
Reviewers: kcc
Subscribers: dberris
Differential Revision: https://reviews.llvm.org/D23425
llvm-svn: 278530
Adding the XFAIL has caused msan to report a different line number in the call
stack (@LINE-3 rather than @LINE-30). The new line number looks more correct
at first glance since it's the line that uses uninitialized memory rather than
the first non-whitespace line of the file but this needs investigating.
llvm-svn: 278516
The mips64el compiler-rt build has recently been enabled. XFAIL the failing
tests to make the buildbot green again.
The two asan tests require the integrated assembler. This will be fixed soon
for Debian mips64el but not for any other mips64el targets since doing so
requires triple-related issues to be fixed..
The msan tests are largely failing because caused by a kernel update (a patch
has already been posted for this).
I'm not sure why the dfsan test fails yet.
llvm-svn: 278504
With this change, the default behavior on error is to call abort()
instead of _exit(). This should help the OS to capture a tombstone of
the error.
RAM usage of the lit test suite goes up because of all the tombstone
gathering, so I'm limiting the parallelism of the test target.
Previously it was based on the number of the CPUs on the host
machine, which is definitely wrong.
llvm-svn: 278308
The API is intended to be used by user to do fine
grained (per-region) control of profile dumping.
Differential Revision: http://reviews.llvm.org/D23106
llvm-svn: 278092
Summary:
Adds a new, generic, resizing hashtable data structure for use by esan
tools. No existing sanitizer hashtable is suitable for the use case for
most esan tools: we need non-fixed-size tables, parameterized keys and
payloads, and write access to payloads. The new hashtable uses either
simple internal or external mutex locking and supports custom hash and
comparision operators. The focus is on functionality, not performance, to
catalyze creation of a variety of tools. We can optimize the more
successful tools later.
Adds tests of the data structure.
Reviewers: aizatsky
Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D22681
llvm-svn: 278024
Summary:
We also add one test (and the XRay testing infrastructure) to exercise
the patching and unpatching code. This uses the XRay API exported
through the headers as well, installing a custom log handler.
Depends on D23101 for the updated emitted code alignment for the
return/entry sleds.
Reviewers: rSerge, echristo, rnk
Subscribers: tberghammer, danalbert, srhines, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D23154
llvm-svn: 277971
Go back to intercepting kernel32!RaiseException, and only go for
ntdll!RtlRaiseException if that fails. Fixes throw_and_catch.cc test.
Work around an issue in LLVM's win64 epilogues. We end up with an
epilogue that looks like this, and it drives the Win64 unwinder crazy
until stack overflow:
call ill_cc!__asan_handle_no_return
xor eax,eax
add rsp,40h // epilogue starts
pop rbp // CSR
ud2 // Trap here
ret // Ret?
nop word ptr [rax+rax]
sub rsp,28h // Next function
Will file a PR soon.
llvm-svn: 277874
Summary:
Often, a code will call multiple virtual methods of a given object.
If they go in a linear block, it should be possible to check vtable
before the first call, then store vtable pointer and reuse it for
the second vcall without any additional checks.
This is expected to have a positive performance impact on a hot
path in Blink, see https://crbug.com/634139.
Reviewers: kcc
Differential Revision: https://reviews.llvm.org/D23151
llvm-svn: 277795
Since the directory is empty on Darwin, disable the inclusion and avoid
the warning below. Exclude on Android as well to match the behavior from
lib/interception/tests/CMakeLists.txt
lit.py:
/Users/buildslave/jenkins/sharedspace/clang-R_master@2/llvm/utils/lit/lit/discovery.py:224:
warning: input
'/Users/buildslave/jenkins/sharedspace/clang-R_master@2/clang-build/Build/tools/clang/runtime/compiler-rt-bins/test/interception/Unit'
contained no tests
This fixes the above warning in some of public bots, like
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/8686
Differential Revision: https://reviews.llvm.org/D23128
rdar://problem/27581108
llvm-svn: 277692
Summary:
-lowertypetests-bitsets-level controls which kinds of bitsets
are generated, as introduced in r277556. This change adds tests
to compiler-rt.
Reviewers: kcc
Differential Revision: https://reviews.llvm.org/D23103
llvm-svn: 277632
Summary:
Respect the handle_sigill common flag and handle_segv flags while we're
at it.
We still handle signals/exceptions differently on Unix and Windows. The
installation process is tricky on Windows, and difficult to push down
into sanitizer_common without concerning it with the different
static/dynamic CRT models on Windows.
Reviewers: kcc, etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23098
llvm-svn: 277621
Summary:
Currently, the Scudo Hardened Allocator only gets its flags via the SCUDO_OPTIONS environment variable.
With this patch, we offer the opportunity for programs to define their own options via __scudo_default_options() which behaves like __asan_default_options() (weak symbol).
A relevant test has been added as well, and the documentation updated accordingly.
I also used this patch as an opportunity to rename a few variables to comply with the LLVM naming scheme, and replaced a use of Report with dieWithMessage for consistency (and to avoid a callback).
Reviewers: llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D23018
llvm-svn: 277536
Summary:
On my install of Windows 10, RaiseException is a tail call to
kernelbase!RaiseException. Obviously, we fail to intercept that.
Instead, try hooking at the ntdll!RtlRaiseException layer. It is
unlikely that this layer will contain control flow.
Intercepting at this level requires adding a decoding for
'LEA ESP, [ESP + 0xXXXXXXXX]', which is a really obscure way to write
'SUB ESP, 0xXXXXXXXX' that avoids clobbering EFLAGS.
Reviewers: etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23046
llvm-svn: 277518
We no longer assign ids to unregistered threads. We don't have any stack
trace for thread creation for these worker threads, so this shouldn't
affect report quality much.
llvm-svn: 277514
Summary:
On Windows 10, this gets called after TLS has been torn down from NTDLL,
and we crash attempting to return fake_tsd. This interceptor isn't
needed after r242948 anyway, so let's remove it. The ASan runtime can
now tolerate unregistered threads calling __asan_handle_no_return.
Reviewers: vitalybuka, etienneb
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23044
llvm-svn: 277478
The system implementation of OSAtomicTestAndClear returns the original bit, but the TSan interceptor has a bug which always returns zero from the function. This patch fixes this and adds a test.
Differential Revision: https://reviews.llvm.org/D23061
llvm-svn: 277461
On Darwin, there are some apps that rely on realloc(nullptr, 0) returning a valid pointer. TSan currently returns nullptr in this case, let's fix it to avoid breaking binary compatibility.
Differential Revision: https://reviews.llvm.org/D22800
llvm-svn: 277458
When we run halt_on_error-torture.cc with 10 threads and 20 iterations with halt_on_error=false:suppress_equal_pcs=false, we write 200 reports to 10.txt file and sometimes have collisions.
We have CHECK-COLLISION check that greps 'AddressSanitizer: nested bug in the same thread, aborting' message in 10.txt, but it doesn't contain this line.
If I don't redirect stderr > 10.txt 'AddressSanitizer: nested bug in the same thread, aborting' is printed to my screen as expected.
Same happens for halt_on_error_suppress_equal_pcs.cc and halt_on_error-torture.cc. This happens because of kernel bug: https://lkml.org/lkml/2014/2/17/324
Furtunately, we can fix these tests by implicitly setting O_APPEND for opened files (use >> instead of > for stderr redirection).
Differential Revision: https://reviews.llvm.org/D22921
llvm-svn: 277324
Summary:
Test where broken because of missing lifetime markers for temps and
because of aggressive optimization which removed markers in some cases.
PR27453
Reviewers: eugenis, kcc
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D22894
llvm-svn: 277074
Summary:
The unittests recently added were not running when executing 'check-all'.
Tests are stable on every archictetures and we can now turn them on.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22695
llvm-svn: 276881
When we delay signals we can deliver them when the signal
is blocked. This can be surprising to the program.
Intercept signal blocking functions merely to process
pending signals. As the result, at worst we will delay
a signal till return from the signal blocking function.
llvm-svn: 276876
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
The OOM test should really only run on 32-bits, since it's hard to OOM
on x64.
The operator_array_new_with_dtor_left_oob tests need to account for the
larger array cookie on x64 (8 bytes instead of 4).
Use -std=c++14 in use-after-scope-capture.cc to avoid errors in the MSVC
2015 STL on Windows. The default there is C++14 anyway.
llvm-svn: 276332
Summary:
This patch is fixing running interception unittests for memcpy/memmove on
windows 64.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22641
llvm-svn: 276324
Diana Picus