dlclose itself might touch it, so better return it to the state it was
before. I don't know how to create a test for this as it would require
chaning dlclose itself.
llvm-svn: 314415
compunit's .data section. This vector is not poisoned. Because of this the
first symbol of the following section has no left red zone. As a result, ASan
cannot detect underflow for such symbols.
Poison ASan allocated metadata, it should not be accessible to user code.
This fix does not eliminate the problem with missing left red zones but it
reduces the set of vulnerable symbols from first symbols in each input data
section to first symbols in the output section of the binary.
Differential Revision: https://reviews.llvm.org/D38056
llvm-svn: 314365
Don't overwrite exit code in LSan when running on top of ASan in recovery mode
to avoid breakage of users code due to found leaks.
Patch by Slava Barinov.
Differential Revision: https://reviews.llvm.org/D38026
llvm-svn: 313966
This is used only to make fast = true in GetStackTraceWithPcBpAndContext
on SANITIZER_FREEBSD and SANITIZER_NETBSD and can be done explicitly.
llvm-svn: 313517
Fuchsia's lowest API layer has been renamed from Magenta to Zircon.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37770
llvm-svn: 313106
ld.config.txt defines linker namespaces in a way that is incompatible
with ASan. Remove the file when installing ASan on an Android O
(8.0.x) device.
Patch by Jiyong Park.
llvm-svn: 312581
Summary:
The NetBSD's 8(beta) versions of kernel functions to retrieve
program name (vnode to path translator) and process memory
map have internal limit of processing filenames with maximum
of 31 characters.
Filenames like Asan-x86_64-with-calls-Noinst-Test break this
limit and affect tests. Rename "-with-calls" to "-calls".
This changes fixes all issues for the Address Sanitizer test
target (check-asan) on the current NetBSD support caused
by long filenames.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, filcab, fjricci, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D37149
llvm-svn: 311966
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311924
Heretofore asan_handle_no_return was used only by interceptors,
i.e. code private to the ASan runtime. However, on systems without
interceptors, code like libc++abi is built with -fsanitize=address
itself and should call asan_handle_no_return directly from
__cxa_throw so that no interceptor is required.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D36811
llvm-svn: 311869
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311842
into a function.
Most CMake configuration under compiler-rt/lib/*/tests have
almost-the-same-but-not-quite functions of the form add_X_[unit]tests
for compiling and running the tests.
Much of the logic is duplicated with minor variations across different
sub-folders.
This can harm productivity for multiple reasons:
For newcomers, resulting CMake files are very large, hard to understand,
and hide the intention of the code.
Changes for enabling certain architectures end up being unnecessarily
large, as they get duplicated across multiple folders.
Adding new sub-projects requires more effort than it should, as a
developer has to again copy-n-paste the configuration, and it's not even
clear from which sub-project it should be copy-n-pasted.
With this change the logic of compile-and-generate-a-set-of-tests is
extracted into a function, which hopefully makes writing and reading
CMake much easier.
Differential Revision: https://reviews.llvm.org/D36116
llvm-svn: 310971
Detect ObjC files in `clang_compile` and pass an appropriate flag to a
compiler, also change `clang_compile` to a function.
Differential Revision: https://reviews.llvm.org/D36727
llvm-svn: 310945
Change macro to a function, move creating test directory into
`add_compiler_rt_test`.
Differential Revision: https://reviews.llvm.org/D36724
llvm-svn: 310943
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: fjricci, vitalybuka, joerg, kcc, filcab
Reviewed By: vitalybuka
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36488
llvm-svn: 310647
Summary:
This is a pure refactoring change. It paves the way for OS-specific
implementations, such as Fuchsia's, that can do most of the
per-thread bookkeeping work in the creator thread before the new
thread actually starts. This model is simpler and cleaner, avoiding
some race issues that the interceptor code for thread creation has
to do for the existing OS-specific implementations.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: phosek, filcab, llvm-commits, kubamracek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36385
llvm-svn: 310432
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, fjricci, vitalybuka, filcab
Reviewed By: fjricci
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36376
llvm-svn: 310414
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, filcab, vitalybuka, kcc, fjricci
Reviewed By: fjricci
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36484
llvm-svn: 310413
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, vitalybuka, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36470
llvm-svn: 310400
Summary:
Do not include <malloc.h> on NetBSD, as this header
serves on this OS backward compatibility with K&R alias
for <stdlib.h>.
Sponsored by <The NetBSD Foundation>
Reviewers: vitalybuka, kcc, joerg, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36469
llvm-svn: 310391
Summary:
r310244 fixed a bug introduced by r309914 for non-Fuchsia builds.
In doing so it also reversed the intended effect of the change for
Fuchsia builds, which was to allow all the AllocateFromLocalPool
code and its variables to be optimized away entirely.
This change restores that optimization for Fuchsia builds, but
doesn't have the original change's bug because the comparison
arithmetic now takes into account the size of the elements.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36430
llvm-svn: 310330
Summary:
Include <stdarg.h> for variable argument list macros (va_list, va_start etc).
Add fallback definition of _LIBCPP_GET_C_LOCALE, this is required for
GNU libstdc++ compatibility. Define new macro SANITIZER_GET_C_LOCALE.
This value is currently required for FreeBSD and NetBSD for printf_l(3) tests.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, vitalybuka, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: llvm-commits, emaste, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36406
llvm-svn: 310323
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, vitalybuka, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: davide, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36377
llvm-svn: 310322
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, fjricci, vitalybuka, filcab, kcc
Reviewed By: vitalybuka
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36374
llvm-svn: 310247
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, filcab, kcc, fjricci, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36375
llvm-svn: 310246
Summary:
Last one of the `pvalloc` overflow checks!
`CheckForPvallocOverflow` was introduced with D35818 to detect when `pvalloc`
would wrap when rounding up to the next multiple of the page size.
Add this check to ASan's `pvalloc` implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D36257
llvm-svn: 310119
Summary:
Fuchsia uses the "memintrinsics" interceptors, though not via any
generalized interception mechanism. It doesn't use any other interceptors.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, phosek, filcab, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36189
llvm-svn: 309798
Currently there's a large amount of CMake logic duplication for
compiling sanitizer tests.
If we add more sanitizers, the duplication will get even worse.
This change factors out common compilation commands into a macro
available to all sanitizers.
llvm-svn: 309405
This change adds sanitizer support for LLVM's libunwind and libc++abi
as an alternative to libstdc++. This allows using the in tree version
of libunwind and libc++abi which is useful when building a toolchain
for different target.
Differential Revision: https://reviews.llvm.org/D34501
llvm-svn: 309362
This change adds support for compiler-rt builtins as an alternative
compiler runtime to libgcc.
Differential Revision: https://reviews.llvm.org/D35165
llvm-svn: 309361
This patch addresses two issues:
Most of the time, hacks with `if/else` in order to get support for
multi-configuration builds are superfluous.
The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it
expands to `.` on all single-configuration builds, and to a configuration
name otherwise.
The `if/else` hacks for the library name generation should also not be
done, as CMake has `TARGET_FILE` generator expression precisely for this
purpose, as it expands to the exact filename of the resulting target.
Differential Revision: https://reviews.llvm.org/D35952
llvm-svn: 309341
This patch addresses two issues:
Most of the time, hacks with `if/else` in order to get support for
multi-configuration builds are superfluous.
The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it
expands to `.` on all single-configuration builds, and to a configuration
name otherwise.
The `if/else` hacks for the library name generation should also not be
done, as CMake has `TARGET_FILE` generator expression precisely for this
purpose, as it expands to the exact filename of the resulting target.
Differential Revision: https://reviews.llvm.org/D35952
llvm-svn: 309306
This change adds sanitizer support for LLVM's libunwind and libc++abi
as an alternative to libstdc++. This allows using the in tree version
of libunwind and libc++abi which is useful when building a toolchain
for different target.
Differential Revision: https://reviews.llvm.org/D34501
llvm-svn: 309074
This change adds support for compiler-rt builtins as an alternative
compiler runtime to libgcc.
Differential Revision: https://reviews.llvm.org/D35165
llvm-svn: 309060
Summary:
This is a pure refactoring change. It just moves code that is
related to filesystem operations from sanitizer_common.{cc,h} to
sanitizer_file.{cc,h}. This makes it cleaner to disable the
filesystem-related code for a new port that doesn't want it.
Submitted on behalf of Roland McGrath.
Reviewers: kcc, eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: vitalybuka, llvm-commits, kubamracek, mgorny, phosek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35591
llvm-svn: 308819
This is a pure refactoring change. It just moves code that is
related to filesystem operations from sanitizer_common.{cc,h} to
sanitizer_file.{cc,h}. This makes it cleaner to disable the
filesystem-related code for a new port that doesn't want it.
Commiting for mcgrathr.
Reviewers: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35591
llvm-svn: 308640
This is a pure refactoring change. It simply moves all the code and
macros related to defining the ASan interceptor versions of memcpy,
memmove, and memset into a separate file. This makes it cleaner to
disable all the other interceptor code while still using these three,
for a port that defines these but not the other common interceptors.
Reviewers: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35590
llvm-svn: 308575
Summary:
Calling exit() from an atexit handler is undefined behavior.
On Linux, it's unavoidable, since we cannot intercept exit (_exit isn't called
if a user program uses return instead of exit()), and I haven't
seen it cause issues regardless.
However, on Darwin, I have a fairly complex internal test that hangs roughly
once in every 300 runs after leak reporting finishes, which is resolved with
this patch, and is presumably due to the undefined behavior (since the Die() is
the only thing that happens after the end of leak reporting).
In addition, this is the way TSan works as well, where an atexit handler+Die()
is used on Linux, and an _exit() interceptor is used on Darwin. I'm not sure if it's
intentionally structured that way in TSan, since TSan sets up the atexit handler and the
_exit() interceptor on both platforms, but I have observed that on Darwin, only the
_exit() interceptor is used, and on Linux the atexit handler is used.
There is some additional related discussion here: https://reviews.llvm.org/D35085
Reviewers: alekseyshl, kubamracek
Subscribers: eugenis, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D35513
llvm-svn: 308353
Summary:
ASan/MSan/LSan allocators set errno on allocation failures according to
malloc/calloc/etc. expected behavior.
MSan allocator was refactored a bit to make its structure more similar
with other allocators.
Also switch Scudo allocator to the internal errno definitions.
TSan allocator changes will follow.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D35275
llvm-svn: 308344
These tests assume allocator_may_return_null=false
If allocator_may_return_null=true, gtest would not be able to switch it.
Tests needs to be re-implemented as lit tests.
llvm-svn: 308254
Summary:
Set proper errno code on alloction failures and change some
implementations to satisfy their man-specified requirements:
LSan: valloc and memalign
ASan: pvalloc, memalign and posix_memalign
Changing both allocators in one patch since LSan depends on ASan allocator in some configurations.
Reviewers: vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D35440
llvm-svn: 308064
On iOS/AArch64, the address space is very limited and has a dynamic maximum address based on the configuration of the device. We're already using a dynamic shadow, and we find a large-enough "gap" in the VM where we place the shadow memory. In some cases and some device configuration, we might not be able to find a large-enough gap: E.g. if the main executable is linked against a large number of libraries that are not part of the system, these libraries can fragment the address space, and this happens before ASan starts initializing.
This patch has a solution, where we have a "backup plan" when we cannot find a large-enough gap: We will restrict the address space (via MmapFixedNoAccess) to a limit, for which the shadow limit will fit.
Differential Revision: https://reviews.llvm.org/D35098
llvm-svn: 307865
Summary:
This is the first in a series of patches to refactor sanitizer_procmaps
to allow MachO section information to be exposed on darwin.
In addition, grouping all segment information in a single struct is
cleaner than passing it through a large set of output parameters, and
avoids the need for annotations of NULL parameters for unneeded
information.
The filename string is optional and must be managed and supplied by the
calling function. This is to allow the MemoryMappedSegment struct to be
stored on the stack without causing overly large stack sizes.
Reviewers: alekseyshl, kubamracek, glider
Subscribers: emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D35135
llvm-svn: 307688
Do this by removing SANITIZER_INTERCEPT_WCSLEN and intercept wcslen
everywhere. Before this change, we were already intercepting wcslen on
Windows, but the interceptor was in asan, not sanitizer_common. After
this change, we stopped intercepting wcslen on Windows, which broke
asan_dll_thunk.c, which attempts to thunk to __asan_wcslen in the ASan
runtime.
llvm-svn: 306706
Summary:
Operator new interceptors behavior is now controlled by their nothrow
property as well as by allocator_may_return_null flag value:
- allocator_may_return_null=* + new() - die on allocation error
- allocator_may_return_null=0 + new(nothrow) - die on allocation error
- allocator_may_return_null=1 + new(nothrow) - return null
Ideally new() should throw std::bad_alloc exception, but that is not
trivial to achieve, hence TODO.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34731
llvm-svn: 306604
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
Summary:
This is required for standalone LSan to work with libdispatch worker threads,
and is a slimmed down version of the functionality provided for ASan
in asan_mac.cc.
Re-commit of r305695 with use_stacks=0 to get around a racy lingering pointer.
Reviewers: alekseyshl, kubamracek, glider, kcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D34247
llvm-svn: 305732
Summary:
CombinedAllocator::Allocate cleared parameter is not used anywhere and
seem to be obsolete.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34289
llvm-svn: 305590
Summary:
Move the OOM decision based on RSS limits out of generic allocator to
ASan allocator, where it makes more sense at the moment.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34180
llvm-svn: 305342
This patch addresses PR 33206. There might be a situation when dynamic ASan runtime initializes later
than shared library which has malloc in static constructor (rtld doesn't provide an order of shared libs initialization).
In this case ASan hasn't yet initialized interceptors, but already intercepts malloc.
If malloc is too big to be handled by static local pool, ASan will die with error:
Sanitizer CHECK failed: lib/asan/asan_malloc_linux.cc:40 ((allocated_for_dlsym)) < ((kDlsymAllocPoolSize)) (1036, 1024)
Patch by Denis Khalikov.
Differential Revision: https://reviews.llvm.org/D33784
llvm-svn: 305058
r304285 - [sanitizer] Avoid possible deadlock in child process after fork
r304297 - [sanitizer] Trying to fix MAC buildbots after r304285
These changes create deadlock when Tcl calls pthread_create from a
pthread_atfork child handler. More info in the original review at
https://reviews.llvm.org/D33325
llvm-svn: 304735
This patch addresses https://github.com/google/sanitizers/issues/774. When we
fork a multi-threaded process it's possible to deadlock if some thread acquired
StackDepot or allocator internal lock just before fork. In this case the lock
will never be released in child process causing deadlock on following memory alloc/dealloc
routine. While calling alloc/dealloc routines after multi-threaded fork is not allowed,
most of modern allocators (Glibc, tcmalloc, jemalloc) are actually fork safe. Let's do the same
for sanitizers except TSan that has complex locking rules.
Differential Revision: https://reviews.llvm.org/D33325
llvm-svn: 304285
Summary:
D33521 addressed a memory ordering issue in BlockingMutex, which seems
to be the cause of a flakiness of a few ASan tests on PowerPC.
Reviewers: eugenis
Subscribers: kubamracek, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33569
llvm-svn: 303995
Summary:
allow_user_segv_handler had confusing name did not allow to control behavior for
signals separately.
Reviewers: eugenis, alekseyshl, kcc
Subscribers: llvm-commits, dberris, kubamracek
Differential Revision: https://reviews.llvm.org/D33371
llvm-svn: 303941
Summary:
This flags is not covered by tests on Windows and looks like it's implemented
incorrectly. Switching its default breaks some tests.
Taking into account that related handle_segv flag is not supported on Windows
it's safer to remove it until we commit to support it.
Reviewers: eugenis, zturner, rnk
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33471
llvm-svn: 303728
It's used in asan_test.cc also on Windows, and my build was failing
with:
C:/src/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc:549:28: error: unknown type name 'jmp_buf'
NOINLINE void LongJmpFunc1(jmp_buf buf) {
^
C:/src/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc:569:10: error: unknown type name 'jmp_buf'
static jmp_buf buf;
^
I couldn't find what changed to make this not work anymore, but this should fix
it.
llvm-svn: 303273
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
Summary:
glibc on Linux calls __longjmp_chk instead of longjmp (or _longjmp) when
_FORTIFY_SOURCE is defined. Ensure that an ASAN-instrumented program
intercepts this function when a system library calls it, otherwise the
stack might remain poisoned and result in CHECK failures and false
positives.
Fixes https://github.com/google/sanitizers/issues/721
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D32408
llvm-svn: 302152
Summary:
On PowerPC and ARM (possibly, need to verify), couple tests involving
pthread_exit fail due to leaks detected by LSan. pthread_exit tries
to perform unwinding that leads to dlopen'ing libgcc_s.so. dlopen
mallocs "libgcc_s.so" string which confuses LSan, it fails to
realize that this allocation happens in dynamic linker and should
be ignored.
Symbolized leak report is required to define a suppression for this
known problem.
Reviewers: eugenis
Subscribers: aemerson, rengolin, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32194
Turn symbolization on for PPC and Thumb only to do not slow down other platforms.
llvm-svn: 300748
We seem to assume that OS-provided thread IDs are either uptr or int, neither of which is true on Darwin. This introduces a tid_t type, which holds a OS-provided thread ID (gettid on Linux, pthread_threadid_np on Darwin, pthread_self on FreeBSD).
Differential Revision: https://reviews.llvm.org/D31774
llvm-svn: 300473
The patch addresses https://github.com/google/sanitizers/issues/786. Currently AsanCheckDynamicRTPrereqs prevents
dynamic ASan runtime from running in some important environments e.g. cowbuilder and fakeroot that may also work with interposition.
Let's allow users to switch off the check given that they know what they do.
Differential Revision: https://reviews.llvm.org/D31420
llvm-svn: 299188
When -fsanitize-address-use-after-scope is used, the instrumentation produces line numbers in stack frame descriptions. This patch make sure the ASan runtime supports this format (ParseFrameDescription needs to be able to parse "varname:line") and prepares lit tests to allow line numbers in ASan report output.
Differential Revision: https://reviews.llvm.org/D31484
llvm-svn: 299043
Summary:
I know of two implementations that do this (ASan is not protecting against accessing the returned memory for now, just like malloc(0)):
SIE libc on the PS4
dlmalloc has a flag for this
This allows us to properly support this behaviour.
Reviewers: vsk, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31295
llvm-svn: 299016
This test case occassionally hangs when run on powerpc. This is also a
problem on AArch64 (see https://bugs.llvm.org/show_bug.cgi?id=24389).
Reactivate this when the problem is fixed.
This could also be related to the same problem as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, and several
others that do not run reliably on powerpc.
llvm-svn: 298873
Revert "Fix sanitizer tests with LLVM_TOOL_LLD_BUILD=OFF."
Revert "[asan] Remove gc-sections test with bfd."
Revert "[asan] Disable globals-gc test with ld.bfd."
Revert "[asan] Fix dead stripping of globals on Linux (compiler-rt)"
OOM in gold linker.
llvm-svn: 298287
Runtime support for the new instrumentation of globals based on !associated, and a bunch of tests.
Differential Revision: https://reviews.llvm.org/D30120
llvm-svn: 298159
Summary: This is useful in some platforms where one of these signals is special.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30783
llvm-svn: 297665
People keep hitting on spurious failures in malloc/free routines when using sanitizers
with shared libraries dlopened with RTLD_DEEPBIND (see https://github.com/google/sanitizers/issues/611 for details).
Let's check for this flag and bail out with warning message instead of failing in random places.
Differential Revision: https://reviews.llvm.org/D30504
llvm-svn: 297370
Summary: Points the user to look at function pointer assignments.
Reviewers: kcc, eugenis, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30432
llvm-svn: 296653
Summary: Points the user to look at function pointer assignments.
Reviewers: kcc, eugenis, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30432
llvm-svn: 296419
Summary: On windows 10, the ucrt DLL is performing allocations before the function hooking and there are multiple allocations not handled by Asan. When a free occur at the end of the process, asan is reporting desallocations not malloc-ed.
Reviewers: rnk, kcc
Reviewed By: rnk, kcc
Subscribers: kcc, llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D25946
llvm-svn: 295730
Summary:
Adds a new cmake flag 'COMPILER_RT_ENABLE_LSAN_OSX', which enables lsan
compilation and is turned off by default. Patches to fix build errors
when this flag is enabled will be uploaded soon.
This is part of an effort to port LSan to OS X, but LSan on OS X does not
currently work or pass tests currently.
Reviewers: kubamracek, kcc, glider, alekseyshl
Reviewed By: kubamracek
Subscribers: danalbert, srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29783
llvm-svn: 295012
When building for Windows, we would check if we were using MSVC rather
than WIN32. This resulted in needed targets not being defined by
sanitizer_common. Fix the conditional.
When registering the objects libraries for ASAN, we would multiply
register for all targets as we were creating them inside a loop over all
architectures. Only define the target per architecture.
llvm-svn: 294510
With universal_newlines, readline() stalls to fill the buffer. Therefore, let the pipe unbuffered.
This is part of https://reviews.llvm.org/D27404
FIXME: Use Popen.communicate()
llvm-svn: 294303
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
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
In Windows, when the sanitizer is implemented as a shared library (DLL), we need
an auxiliary static library dynamic_runtime_thunk that will be linked to the
main executable and dlls.
In the sanitizer DLL, we are exposing weak functions with WIN_WEAK_EXPORT_DEF(),
which exports the default implementation with __dll suffix. For example: for
sanitizer coverage, the default implementation of __sanitizer_cov_trace_cmp is
exported as: __sanitizer_cov_trace_cmp__dll.
In the dynamic_runtime_thunk static library, we include weak aliases to the
imported implementation from the dll, using the macro WIN_WEAK_IMPORT_DEF().
By default, all users's programs that include calls to weak functions like
__sanitizer_cov_trace_cmp, will be redirected to the implementation in the dll,
when linking to dynamic_runtime_thunk.
After this diff, we are able to compile code with sanitizer coverage
instrumentation on Windows. When the instrumented object files are linked with
clang-rt_asan_dynamic_runtime_thunk-arch.lib all the weak symbols will be
resolved to the implementation imported from asan dll.
All the files sanitizer_dynamic_runtime_thunk.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we compile: [asan|ubsan|sanitizer_coverage]_win_dynamic_runtime_thunk.cc
and sanitizer_win_dynamic_runtime_thunk.cc to generate
asan_dynamic_runtime_thunk.lib, because we include asan, ubsan and sanitizer
coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29158
llvm-svn: 293953
In this diff, I update current implementation of the interception in dll_thunks
to consider the special case of weak functions.
First we check if the client has redefined the function in the main executable
(for example: __sanitizer_cov_trace_pc_guard). It we can't find it, then we look
for the default implementation (__sanitizer_cov_trace_pc_guard__dll). The
default implementation is always available because the static runtime is linked
to the main executable.
Differential Revision: https://reviews.llvm.org/D29155
llvm-svn: 293952
When the sanitizer is implemented as a static library and is included in the
main executable, we need an auxiliary static library dll_thunk that will be
linked to the dlls that have instrumentation, so they can refer to the runtime
in the main executable. Basically, it uses interception to get a pointer the
function in the main executable and override its function with that pointer.
Before this diff, all of the implementation for dll_thunks was included in asan.
In this diff I split it into different sanitizers, so we can use other
sanitizers regardless of whether we include asan or not.
All the sanitizers include a file sanitizer_win_dll_thunk.cc that register
functions to be intercepted in the binary section: DLLTH
When the dll including dll_thunk is initialized, it will execute
__dll_thunk_init() implemented in: sanitizer_common/sanitizer_win_dll_thunk.cc,
which will consider all the CB registered in the section DLLTH. So, all the
functions registered will be intercepted, and redirected to the implementation
in the main executable.
All the files "sanitizer_win_dll_thunk.cc" are independent, so we don't need to
include a specific list of sanitizers. Now, we compile: asan_win_dll_thunk.cc
ubsan_win_dll_thunk.cc, sanitizer_coverage_win_dll_thunk.cc and
sanitizer_win_dll_thunk.cc, to generate asan_dll_thunk, because we include asan,
ubsan and sanitizer coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29154
llvm-svn: 293951
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
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
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
This patch adds some useful macros for dealing with pragma directives on
Windows. Also, I add appropriate documentation for future users.
Differential Revision: https://reviews.llvm.org/D28525
llvm-svn: 292650
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
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
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291417
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291314
This patch teaches asan_symbolize.py to read an architecture suffix on module names (e.g. ":x86_64") and pass that option to atos and llvm-symbolizer.
Differential Revision: https://reviews.llvm.org/D27378
llvm-svn: 291280
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
Summary:
Make kLargeMalloc big enough to be handled by secondary allocator
and small enough to fit into quarantine for all configurations.
It become too big to fit into quarantine on Android after D27873.
Reviewers: eugenis
Patch by Alex Shlyapnikov.
Subscribers: danalbert, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D28142
llvm-svn: 290689
Evgeniy Stepanov