Summary:
NetBSD ships with __errno (value for __errno_location) like Android.
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, vitalybuka, fjricci, kcc, filcab
Reviewed By: vitalybuka
Subscribers: llvm-commits, srhines, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36360
llvm-svn: 310182
Summary:
NetBSD is a POSIX-like and BSD-family system.
Reuse FreeBSD and Linux code.
NetBSD uses DWARF ExceptionHandler.
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, filcab, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, emaste, llvm-commits, kubamracek, aprantl, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36314
llvm-svn: 310179
Summary:
When possible reuse FreeBSD and Linux code.
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
Reviewed By: vitalybuka
Subscribers: srhines, emaste, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36320
llvm-svn: 310143
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, filcab, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36323
llvm-svn: 310140
Summary:
This adds:
- NetBSD specific aliases for renamed syscalls,
- differentiate internal_syscall, internal_syscall64, internal_syscall_ptr as there are various types of syscalls on NetBSD.
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
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36316
llvm-svn: 310139
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:
This adds NetBSD specific:
- ReadProcMaps()
- MemoryMappingLayout::Next()
This code is largely shared with FreeBSD.
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: kcc, joerg, filcab, vitalybuka, fjricci
Reviewed By: fjricci
Subscribers: emaste, kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35551
llvm-svn: 310116
Summary:
The regular expression to match STL allocators can't easily account for
C++ mangling compression and fails to match some valid instances of STL
allocators. Perform this logic in clang instead.
Motivated by crbug.com/751385.
Reviewers: pcc, kcc, llvm-commits
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D36291
llvm-svn: 310109
This fixes a bug in the ReadFromSymbolizer method of the
Addr2LineProcess class; if the input is too large, the returned buffer
will be null and will consequently fail the CHECK. The proposed fix is
to simply check if the buffer consists of only a null-terminator and
return if so (in effect skipping that frame). I tested by running one of
the unit tests both before and after my change.
Submitted on behalf of david-y-lam.
Reviewers: eugenis, alekseyshl, kcc
Reviewed By: alekseyshl
Differential Revision: https://reviews.llvm.org/D36207
llvm-svn: 310089
The test was not passing on targets where allocator_may_return_null
defaults to true. Change the test to a lit test so that we can test both
situations.
Patch by Kostya Kortchinsky!
Differential Revision: https://reviews.llvm.org/D36302
llvm-svn: 310033
Tested on MSVC 2013, 2015 and 2017 targeting X86, X64 and ARM.
This fixes building emutls.c for Windows for ARM (both with clang
which don't need these atomics fallbacks at all, but just failed
due to the immintrin.h include before, and with MSVC).
Differential Revision: https://reviews.llvm.org/D36071
llvm-svn: 309974
Summary:
Define a build-time configuration option for the XRay runtime to
determine whether the archive will add an entry to the `.preinit_array`
section of the binary. We also allow for initializing the XRay data
structures with an explicit call to __xray_init(). This allows us to
give users the capability to initialize the XRay data structures on
demand.
This can allow us to start porting XRay to platforms where
`.preinit_array` isn't a supported section. It also allows us to limit
the effects of XRay in the initialization sequence for applications that
are sensitive to this kind of interference (i.e. large binaries) or
those that want to package XRay control in libraries.
Future changes should allow us to build two different library archives
for the XRay runtime, and allow clang users to determine which version
to link.
Reviewers: dblaikie, kpw, pelikan
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D36080
llvm-svn: 309909
Summary:
`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 TSan's pvalloc implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D36245
llvm-svn: 309897
Summary:
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 MSan's pvalloc implementation.
This time I made sure I was actually running (and writing) the correct tests,
and that they are passing...
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36164
llvm-svn: 309883
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
Summary:
This change attempts to remove all the dependencies we have on
std::mutex and any std::shared_ptr construction in global variables. We
instead use raw pointers to these objects, and construct them on the
heap. In cases where it's possible, we lazily initialize these pointers.
While we do not have a replacement for std::shared_ptr yet in
compiler-rt, we use this work-around to avoid having to statically
initialize the objects as globals. Subsequent changes should allow us to
completely remove our dependency on std::shared_ptr and instead have our
own implementation of the std::shared_ptr and std::weak_ptr semantics
(or completely rewrite the implementaton to not need these
standard-library provided abstractions).
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36078
llvm-svn: 309792
Summary:
Fuchsia doesn't support built-in symbolization per se at all.
Instead, it always emits a Fuchsia-standard "symbolizer markup"
format that makes it possible for a post-processing filter to
massage the logs into symbolized format. Hence, it does not
support user-specified formatting options for backtraces or other
symbolization.
Reviewers: vitalybuka, alekseyshl, kcc
Subscribers: kubamracek, mgorny, phosek, filcab, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36032
llvm-svn: 309760
Summary:
Fuchsia doesn't support filesystem access per se at low level.
So it won't use any of the filesystem-oriented code in sanitizer_common.
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/D36029
llvm-svn: 309749
Summary:
Actually Fuchsia non-support for interceptors. Fuchsia doesn't use
interceptors in the common sense at all. Almost all system library
functions don't need interception at all, because the system
libraries are just themselves compiled with sanitizers enabled and
have specific hook interfaces where needed to inform the sanitizer
runtime about thread lifetimes and the like. For the few functions
that do get intercepted, they don't use a generic mechanism like
dlsym with RTLD_NEXT to find the underlying system library function.
Instead, they use specific extra symbol names published by the
system library (e.g. __unsanitized_memcpy).
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc, filcab
Reviewed By: filcab
Subscribers: kubamracek, phosek, filcab, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36028
llvm-svn: 309745
Summary:
Reverting D36093 until I can figure out how to launch the correct tests :/
My apologies.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36120
llvm-svn: 309637
Summary:
`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 MSan's pvalloc implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36093
llvm-svn: 309601
Summary: More changes to follow will add the Fuchsia port.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, phosek, filcab
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36027
llvm-svn: 309539
Lowercase the Windows.h include in enable_execute_stack.c, just as in
emutls.c in SVN r302340.
Differential Revision: https://reviews.llvm.org/D36066
llvm-svn: 309537
Summary:
New systems might be neither Windows nor POSIX. The SI_NOT_WINDOWS
macro in sanitizer_platform_interceptors.h was already effectively
the same as SI_POSIX, so just use SI_POSIX instead.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: vitalybuka
Subscribers: phosek, filcab, llvm-commits, kubamracek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36038
llvm-svn: 309536
Summary:
Currently when the XRay runtime is linked into a binary that doesn't
have the instrumentation map, we print a warning unconditionally. This
change attempts to make this behaviour more quiet.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35789
llvm-svn: 309534
TSan tests on Darwin first link all libraries into a static archive file.
With this change, the linking is done once per all architecture,
and previously the linking step was repeated per each architecture per
each add_tsan_test call.
Furthermore, the code is cleared up.
Differential Revision: https://reviews.llvm.org/D35913
llvm-svn: 309406
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
Summary: In the current implementation, the defaul number of values per site tracked by value profiler is 8, which is too small and could introduce inaccuracies to profile. Changing it to 16 will be able to gain more accurate value profiler.
Reviewers: davidxl, tejohnson
Reviewed By: tejohnson
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D35964
llvm-svn: 309388
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:
Previously we were rounding up the size passed to `pvalloc` to the next
multiple of page size no matter what. There is an overflow possibility that
wasn't accounted for. So now, return null in the event of an overflow. The man
page doesn't seem to indicate the errno to set in this particular situation,
but the glibc unit tests go for ENOMEM (https://code.woboq.org/userspace/glibc/malloc/tst-pvalloc.c.html#54)
so we'll do the same.
Update the aligned allocation funtions tests to check for properly aligned
returned pointers, and the `pvalloc` corner cases.
@alekseyshl: do you want me to do the same in the other Sanitizers?
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, alekseyshl, llvm-commits
Differential Revision: https://reviews.llvm.org/D35818
llvm-svn: 309033
Summary:
__DATA segments on Darwin contain a large number of separate sections,
many of which cannot actually contain pointers, and contain const values or
objc metadata. Not scanning sections which cannot contain pointers significantly
improves performance.
On a medium-sized (~4000 files) internal project, I saw a speedup of about 30%
in standalone LSan's execution time (30% improvement in the time spent running
LSan, not the total program time).
Reviewers: kcc, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35432
llvm-svn: 308999
Summary:
This is a re-upload of the reverted commit r308644. It has changed quite
a bit to reflect post-commit comments by kcc, so I'm re-uploading as
a new review.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35799
llvm-svn: 308977
Summary:
Set proper errno code on allocation failures and change realloc, pvalloc,
aligned_alloc, memalign and posix_memalign implementation to satisfy
their man-specified requirements.
Modify allocator API implementation to bring it closer to other
sanitizers allocators.
Reviewers: dvyukov
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D35690
llvm-svn: 308929
Summary:
Using asm works fine for gnu11, but fails if the compiler uses C11.
Switch to the more consistent __asm__, since that is what the rest of
the source is using.
Reviewers: petarj
Reviewed By: petarj
Subscribers: llvm-commits, sdardis, arichardson, pirama
Differential Revision: https://reviews.llvm.org/D35756
llvm-svn: 308922
atos is the default symbolizer on Apple's compiler for quite a few years now.
llvm-symbolizer is quite fragile on Darwin: for example, unless a .dSYM
file was explicitly generated symbolication would not work.
It is also very convenient when the behavior of LLVM open source
compiler matches to that of Apple's compiler on Apple's platform.
Furthermore, llvm-symbolizer is not installed on Apple's platform by
default, which leads to strange behavior during debugging: the test
might fail under lit (where it has llvm-symbolizer) but would run
properly when launched on the command line (where it does not, and atos
would be used).
Indeed, there's a downside: atos does not work properly with inlined
functions, hence the test change.
We do not think that this is a major problem, as users would often
compile with -O0 when debugging, and in any case it is preferable to
symbolizer not being able to symbolize.
Differential Revision: https://reviews.llvm.org/D35745
llvm-svn: 308908
Summary:
First, some context.
The main feedback we get about the quarantine is that it's too memory hungry.
A single MB of quarantine will have an impact of 3 to 4MB of PSS/RSS, and
things quickly get out of hand in terms of memory usage, and the quarantine
ends up disabled.
The main objective of the quarantine is to protect from use-after-free
exploitation by making it harder for an attacker to reallocate a controlled
chunk in place of the targeted freed chunk. This is achieved by not making it
available to the backend right away for reuse, but holding it a little while.
Historically, what has usually been the target of such attacks was objects,
where vtable pointers or other function pointers could constitute a valuable
targeti to replace. Those are usually on the smaller side. There is barely any
advantage in putting the quarantine several megabytes of RGB data or the like.
Now for the patch.
This patch introduces a new way the Quarantine behaves in Scudo. First of all,
the size of the Quarantine will be defined in KB instead of MB, then we
introduce a new option: the size up to which (lower than or equal to) a chunk
will be quarantined. This way, we only quarantine smaller chunks, and the size
of the quarantine remains manageable. It also prevents someone from triggering
a recycle by allocating something huge. We default to 512 bytes on 32-bit and
2048 bytes on 64-bit platforms.
In details, the patches includes the following:
- introduce `QuarantineSizeKb`, but honor `QuarantineSizeMb` if set to fall
back to the old behavior (meaning no threshold in that case);
`QuarantineSizeMb` is described as deprecated in the options descriptios;
documentation update will follow;
- introduce `QuarantineChunksUpToSize`, the new threshold value;
- update the `quarantine.cpp` test, and other tests using `QuarantineSizeMb`;
- remove `AllocatorOptions::copyTo`, it wasn't used;
- slightly change the logic around `quarantineOrDeallocateChunk` to accomodate
for the new logic; rename a couple of variables there as well;
Rewriting the tests, I found a somewhat annoying bug where non-default aligned
chunks would account for more than needed when placed in the quarantine due to
`<< MinAlignment` instead of `<< MinAlignmentLog`. This is fixed and tested for
now.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35694
llvm-svn: 308884
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
Summary: This will allow sanitizer_procmaps on mac to expose section information.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35422
llvm-svn: 308644
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
Summary:
Reuse Linux, FreeBSD and Apple code - no NetBSD specific changes.
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, vitalybuka, filcab, kcc
Reviewed By: filcab
Subscribers: emaste, kubamracek, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35628
llvm-svn: 308616
Summary:
Reuse Linux and FreeBSD - no NetBSD specific changes.
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, vitalybuka
Reviewed By: filcab
Subscribers: llvm-commits, emaste, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35629
llvm-svn: 308615
Summary:
Reuse Linux and FreeBSD code - no NetBSD specific changes.
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
Reviewed By: filcab
Subscribers: emaste, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35632
llvm-svn: 308614
Summary:
Thread id will be added to VRerort. Having thread here is useful.
This is also common place for logging for all sanitizers, so I can use this in
common test.
Reviewers: kcc, alekseyshl
Subscribers: kubamracek, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D35655
llvm-svn: 308578
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:
__DATA segments on Darwin contain a large number of separate sections,
most of which cannot actually contain pointers, and contain const values or
objc metadata. Only scanning sections which can contain pointers greatly improves
performance.
On a medium-sized (~4000 files) internal project, I saw a speedup of about 50%
in standalone LSan's execution time (50% improvement in the time spent running
LSan, not the total program time).
Reviewers: kcc, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35432
llvm-svn: 308231
Summary:
Without them expressions like this may have different values.
(SANITIZER_INTERCEPT_MEMRCHR && SANITIZER_INTERCEPT_PREADV)
Reviewers: alekseyshl
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D35512
llvm-svn: 308228
Summary:
Introduce SI_NETBSD for NetBSD.
Add NetBSD support for appropriate `SANITIZER_INTERCEPT_*`.
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, dim, kcc, alekseyshl, filcab, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35468
llvm-svn: 308217
Summary:
Add defines for new NetBSD: SANITIZER_NETBSD,
it will be used across the codebase for sanitizers.
NetBSD is a POSIX-like platform, add it to SANITIZER_POSIX.
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, dim, alekseyshl, filcab, eugenis, vitalybuka
Reviewed By: kcc
Subscribers: kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35467
llvm-svn: 308216
Summary: This will allow sanitizer_procmaps on mac to expose section information.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35422
llvm-svn: 308210
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
Set proper errno code on alloction failures and change valloc and
memalign implementations to satisfy their man-specified requirements.
llvm-svn: 308063
Summary:
Set proper errno code on alloction failure and change pvalloc and
posix_memalign implementation to satisfy their man-specified
requirements.
Reviewers: cryptoad
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35429
llvm-svn: 308053
This change implements 2 optimizations of sync clocks that reduce memory consumption:
Use previously unused first level block space to store clock elements.
Currently a clock for 100 threads consumes 3 512-byte blocks:
2 64-bit second level blocks to store clock elements
+1 32-bit first level block to store indices to second level blocks
Only 8 bytes of the first level block are actually used.
With this change such clock consumes only 2 blocks.
Share similar clocks differing only by a single clock entry for the current thread.
When a thread does several release operations on fresh sync objects without intervening
acquire operations in between (e.g. initialization of several fields in ctor),
the resulting clocks differ only by a single entry for the current thread.
This change reuses a single clock for such release operations. The current thread time
(which is different for different clocks) is stored in dirty entries.
We are experiencing issues with a large program that eats all 64M clock blocks
(32GB of non-flushable memory) and crashes with dense allocator overflow.
Max number of threads in the program is ~170 which is currently quite unfortunate
(consume 4 blocks per clock). Currently it crashes after consuming 60+ GB of memory.
The first optimization brings clock block consumption down to ~40M and
allows the program to work. The second optimization further reduces block consumption
to "modest" 16M blocks (~8GB of RAM) and reduces overall RAM consumption to ~30GB.
Measurements on another real world C++ RPC benchmark show RSS reduction
from 3.491G to 3.186G and a modest speedup of ~5%.
Go parallel client/server HTTP benchmark:
https://github.com/golang/benchmarks/blob/master/http/http.go
shows RSS reduction from 320MB to 240MB and a few percent speedup.
Reviewed in https://reviews.llvm.org/D35323
llvm-svn: 308018
Summary:
libsanitizer doesn't build against latest glibc anymore, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066 for details.
One of the changes is that stack_t changed from typedef struct sigaltstack { ... } stack_t; to typedef struct { ... } stack_t; for conformance reasons.
And the other change is that the glibc internal __need_res_state macro is now ignored, so when doing
```
#define __need_res_state
#include <resolv.h>
```
the effect is now the same as just
```
#include <resolv.h>
```
and thus one doesn't get just the
```
struct __res_state { ... };
```
definition, but newly also the
```
extern struct __res_state *__res_state(void) __attribute__ ((__const__));
```
prototype. So __res_state is no longer a type, but a function.
Reviewers: kcc, ygribov
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D35246
llvm-svn: 307969
Summary:
Secondary backed allocations do not require a cache. While it's not necessary
an issue when each thread has its cache, it becomes one with a shared pool of
caches (Android), as a Secondary backed allocation or deallocation holds a
cache that could be useful to another thread doing a Primary backed allocation.
We introduce an additional PRNG and its mutex (to avoid contention with the
Fallback one for Primary allocations) that will provide the `Salt` needed for
Secondary backed allocations.
I changed some of the code in a way that feels more readable to me (eg: using
some values directly rather than going through ternary assigned variables,
using directly `true`/`false` rather than `FromPrimary`). I will let reviewers
decide if it actually is.
An additional change is to mark `CheckForCallocOverflow` as `UNLIKELY`.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35358
llvm-svn: 307958
Summary:
We were missing many feature flags that newer gcc supports and we had our own set of feature flags that gcc didnt' support that were overlapping. Clang's implementation assumes gcc's features list so a mismatch here is problematic.
I've also matched the cpu type/subtype lists with gcc and removed all the cpus that gcc doesn't support. I've also removed the fallback autodetection logic that was taken from Host.cpp. It was the main reason we had extra feature flags relative to gcc. I don't think gcc does this in libgcc.
Once this support is in place we can consider implementing __builtin_cpu_is in clang. This could also be needed for function dispatching that Erich Keane is working on.
Reviewers: echristo, asbirlea, RKSimon, erichkeane, zvi
Reviewed By: asbirlea
Subscribers: dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D35214
llvm-svn: 307878
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
Add Fuchsia support to some builtings and avoid building builtins
that are not and will never be used on Fuchsia.
Differential Revision: https://reviews.llvm.org/D34075
llvm-svn: 307832
Summary:
This follows the addition of `GetRandom` with D34412. We remove our
`/dev/urandom` code and use the new function. Additionally, change the PRNG for
a slightly faster version. One of the issues with the old code is that we have
64 full bits of randomness per "next", using only 8 of those for the Salt and
discarding the rest. So we add a cached u64 in the PRNG that can serve up to
8 u8 before having to call the "next" function again.
During some integration work, I also realized that some very early processes
(like `init`) do not benefit from `/dev/urandom` yet. So if there is no
`getrandom` syscall as well, we have to fallback to some sort of initialization
of the PRNG.
Now a few words on why XoRoShiRo and not something else. I have played a while
with various PRNGs on 32 & 64 bit platforms. Some results are below. LCG 32 & 64
are usually faster but produce respectively 15 & 31 bits of entropy, meaning
that to get a full 64-bit, you would need to call them several times. The simple
XorShift is fast, produces 32 bits but is mediocre with regard to PRNG test
suites, PCG is slower overall, and XoRoShiRo is faster than XorShift128+ and
produces full 64 bits.
%%%
root@tulip-chiphd:/data # ./randtest.arm
[+] starting xs32...
[?] xs32 duration: 22431833053ns
[+] starting lcg32...
[?] lcg32 duration: 14941402090ns
[+] starting pcg32...
[?] pcg32 duration: 44941973771ns
[+] starting xs128p...
[?] xs128p duration: 48889786981ns
[+] starting lcg64...
[?] lcg64 duration: 33831042391ns
[+] starting xos128p...
[?] xos128p duration: 44850878605ns
root@tulip-chiphd:/data # ./randtest.aarch64
[+] starting xs32...
[?] xs32 duration: 22425151678ns
[+] starting lcg32...
[?] lcg32 duration: 14954255257ns
[+] starting pcg32...
[?] pcg32 duration: 37346265726ns
[+] starting xs128p...
[?] xs128p duration: 22523807219ns
[+] starting lcg64...
[?] lcg64 duration: 26141304679ns
[+] starting xos128p...
[?] xos128p duration: 14937033215ns
%%%
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: aemerson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35221
llvm-svn: 307798
1. Add SyncClock::ResetImpl which removes code
duplication between ctor and Reset.
2. Move SyncClock::Resize to SyncClock methods,
currently it's defined between ThreadClock methods.
llvm-svn: 307785
Don't create sync object if it does not exist yet. For example, an atomic
pointer is initialized to nullptr and then periodically acquire-loaded.
llvm-svn: 307778
r307338 enabled new optimization reducing number of operation in tested functions.
There is no any performance regression detectable with TsanRtlTest DISABLED_BENCH.Mop* tests.
llvm-svn: 307739
Cleaner than using a while loop to copy the string character by character.
Reviewers: alekseyshl, glider
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35136
llvm-svn: 307696
Summary:
This function is only called once and is fairly simple. Inline to
keep API simple.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35270
llvm-svn: 307695
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
Printing stacktrace from ASAN crashes with a segfault in DEDUP mode when
symbolication is missing.
Differential Revision: https://reviews.llvm.org/D34914
llvm-svn: 307577
This patch ports the assembly file implementing TSan's setjmp support to AArch64 on Darwin.
Differential Revision: https://reviews.llvm.org/D35143
llvm-svn: 307541
We currently hardcode the maximum VM address on iOS/AArch64, which is not really correct and this value changes between device configurations. Let's use TASK_VM_INFO to retrieve the maximum VM address dynamically.
Differential Revision: https://reviews.llvm.org/D35032
llvm-svn: 307307
The logic in GetMaxVirtualAddress is already pretty complex, and I want to get rid of the hardcoded value for iOS/AArch64, which would need adding more Darwin-specific code, so let's split the implementation into sanitizer_linux.cc and sanitizer_mac.cc files. NFC.
Differential Revision: https://reviews.llvm.org/D35031
llvm-svn: 307281
On Darwin, sigprocmask changes the signal mask for the entire process. This has some unwanted consequences, because e.g. internal_start_thread wants to disable signals only in the current thread (to make the new thread inherit the signal mask), which is currently broken on Darwin. This patch switches to pthread_sigmask.
Differential Revision: https://reviews.llvm.org/D35016
llvm-svn: 307212
Summary:
An attempt to reland D34786 (which caused bot failres on Mac), now with
properly intercepted operators new() and delete().
LSan allocator used to always return nullptr on too big allocation requests
(the definition of "too big" depends on platform and bitness), now it
follows policy configured by allocator_may_return_null flag
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34845
llvm-svn: 306845
Summary:
In `sanitizer_allocator_primary32.h`:
- rounding up in `MapWithCallback` is not needed as `MmapOrDie` does it. Note
that the 64-bit counterpart doesn't round up, this keeps the behavior
consistent;
- since `IsAligned` exists, use it in `AllocateRegion`;
- in `PopulateFreeList`:
- checking `b->Count` to be greater than 0 when `b->Count() == max_count` is
redundant when done more than once. Just check that `max_count` is greater
than 0 out of the loop; the compiler (at least on ARM) didn't optimize it;
- mark the batch creation failure as `UNLIKELY`;
In `sanitizer_allocator_primary64.h`:
- in `MapWithCallback`, mark the failure condition as `UNLIKELY`;
In `sanitizer_posix.h`:
- mark a bunch of Mmap related failure conditions as `UNLIKELY`;
- in `MmapAlignedOrDieOnFatalError`, we have `IsAligned`, so use it; rearrange
the conditions as one test was redudant;
- in `MmapFixedImpl`, 30 chars was not large enough to hold the message and a
full 64-bit address (or at least a 48-bit usermode address), increase to 40.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: aemerson, kubamracek, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D34840
llvm-svn: 306834
Summary:
Due to changes in semantics, CheckForCallocOverflow makes much more sense
now.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34799
llvm-svn: 306747
Users can specify the path a raw profile is written to by passing
-fprofile-instr-generate=<path>, but this functionality broke on Darwin
after __llvm_profile_filename was made weak [1], resulting in profiles
being written to "default.profraw" even when <path> is specified.
The situation is that instrumented programs provide a weak definition of
__llvm_profile_filename, which conflicts with a weak redefinition
provided by the profiling runtime.
The linker appears to pick the 'winning' definition arbitrarily: on
Darwin, it usually prefers the larger definition, which is probably why
the instrprof-override-filename.c test has been passing.
The fix is to move the runtime's definition into a separate object file
within the archive. This means that the linker won't "see" the runtime's
definition unless the user program has not provided one. I couldn't
think of a great way to test this other than to mimic the Darwin
failure: use -fprofile-instr-generate=<some-small-path>.
Testing: check-{clang,profile}, modified instrprof-override-filename.c.
[1] [Profile] deprecate __llvm_profile_override_default_filename
https://reviews.llvm.org/D22613https://reviews.llvm.org/D22614
Differential Revision: https://reviews.llvm.org/D34797
llvm-svn: 306710
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:
We were not following the `man` documented behaviors for invalid arguments to
`memalign` and associated functions. Using `CHECK` for those was a bit extreme,
so we relax the behavior to return null pointers as expected when this happens.
Adapt the associated test.
I am using this change also to change a few more minor performance improvements:
- mark as `UNLIKELY` a bunch of unlikely conditions;
- the current `CHECK` in `__sanitizer::RoundUpTo` is redundant for us in *all*
calls. So I am introducing our own version without said `CHECK`.
- change our combined allocator `GetActuallyAllocatedSize`. We already know if
the pointer is from the Primary or Secondary, so the `PointerIsMine` check is
redundant as well, and costly for the 32-bit Primary. So we get the size by
directly using the available Primary functions.
Finally, change a `int` to `uptr` to avoid a warning/error when compiling on
Android.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34782
llvm-svn: 306698
Summary:
LSan allocator used to always return nullptr on too big allocation requests
(the definition of "too big" depends on platform and bitness), now it
follows policy configured by allocator_may_return_null flag.
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34786
llvm-svn: 306624
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:
This change introduces two files that show exaples of the
always/never instrument files that can be provided to clang. We don't
add these as defaults yet in clang, which we can do later on (in a
separate change).
We also add a test that makes sure that these apply in the compiler-rt
project tests, and that changes in clang don't break the expectations in
compiler-rt.
Reviewers: pelikan, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34669
llvm-svn: 306502
Summary: Cleaner than computing the intersection for each possible sanitizer
Reviewers: compnerd, beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34693
llvm-svn: 306453
Summary: This allows check-all to be used when only a subset of the sanitizers are built.
Reviewers: beanz, compnerd, rnk, pcc
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34644
llvm-svn: 306450
Introduces a 'owner' struct to include the overridable write
method and the write context in C.
This allows easy introdution of new member API to help reduce
profile merge time in the follow up patch.
llvm-svn: 306432
Summary: This allows check-all to be used when only a subset of the sanitizers are built.
Reviewers: beanz, compnerd
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34644
llvm-svn: 306415
Summary:
Make SizeClassAllocator32 return nullptr when it encounters OOM, which
allows the entire sanitizer's allocator to follow allocator_may_return_null=1
policy, even for small allocations (LargeMmapAllocator is already fixed
by D34243).
Will add a test for OOM in primary allocator later, when
SizeClassAllocator64 can gracefully handle OOM too.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34433
llvm-svn: 305972
Summary:
AFAICT compiler-rt doesn't have a function that would return 'good' random
bytes to seed a PRNG. Currently, the `SizeClassAllocator64` uses addresses
returned by `mmap` to seed its PRNG, which is not ideal, and
`SizeClassAllocator32` doesn't benefit from the entropy offered by its 64-bit
counterpart address space, so right now it has nothing. This function aims at
solving this, allowing to implement good 32-bit chunk randomization. Scudo also
has a function that does this for Cookie purposes, which would go away in a
later CL once this lands.
This function will try the `getrandom` syscall if available, and fallback to
`/dev/urandom` if not.
Unfortunately, I do not have a way to implement and test a Mac and Windows
version, so those are unimplemented as of now. Note that `kRandomShuffleChunks`
is only used on Linux for now.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: zturner, rnk, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34412
llvm-svn: 305922
Change some reinterpret_casts to c-style casts due to template instantiation
restrictions and build breakage due to missing paranthesises.
llvm-svn: 305899
Summary:
On Android we still need to reset preinstalled handlers and allow use handlers later.
This reverts commit r304039.
Reviewers: eugenis
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D34434
llvm-svn: 305871
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:
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.
Reviewers: alekseyshl, kubamracek, glider, kcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D34247
llvm-svn: 305695
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
The first instruction of the new ucrtbase!strnlen implementation loads a
global, presumably to dispatch between SSE and non-SSE optimized strnlen
implementations.
Fixes PR32895 and probably
https://github.com/google/sanitizers/issues/818
llvm-svn: 305581
Summary:
Context: https://github.com/google/sanitizers/issues/740.
Making secondary allocator to respect allocator_may_return_null=1 flag
and return nullptr when "out of memory" happens.
More changes in primary allocator and operator new will follow.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34243
llvm-svn: 305569
The dynamic type check needs to inspect vtables, but could crash if it
encounters a vtable pointer to inaccessible memory. In the first attempt
to fix the issue (r304437), we performed a memory accessibility check on
the wrong range of memory. This should *really* fix the problem.
Patch by Max Moroz!
Differential Revision: https://reviews.llvm.org/D34215
llvm-svn: 305489
Summary:
After r303941 it was not possible to setup ASAN_OPTIONS to have the same
behavior for pre r303941 and post r303941 builds.
Pre r303941 Asan does not accept handle_sigbus=2.
Post r303941 Asan does not accept allow_user_segv_handler.
This fix ignores allow_user_segv_handler=1, but for allow_user_segv_handler=0
it will upgrade flags like handle_sigbus=1 to handle_sigbus=2. So user can set
ASAN_OPTIONS=allow_user_segv_handler=0 and have same behavior on old and new
clang builds (except range from r303941 to this revision).
In future users which need to prevent third party handlers should switch to
handle_sigbus=2 and remove allow_user_segv_handler as soon as suport of older
builds is not needed.
Related bugs:
https://github.com/google/oss-fuzz/issues/675https://bugs.chromium.org/p/chromium/issues/detail?id=731130
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34227
llvm-svn: 305433
Summary:
This broke thread_local_quarantine_pthread_join.cc on some architectures, due
to the overhead of the stashed regions. Reverting while figuring out the best
way to deal with it.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34213
llvm-svn: 305404
Summary:
The reasoning behind this change is explained in D33454, which unfortunately
broke the Windows version (due to the platform not supporting partial unmapping
of a memory region).
This new approach changes `MmapAlignedOrDie` to allow for the specification of
a `padding_chunk`. If non-null, and the initial allocation is aligned, this
padding chunk will hold the address of the extra memory (of `alignment` bytes).
This allows `AllocateRegion` to get 2 regions if the memory is aligned
properly, and thus help reduce fragmentation (and saves on unmapping
operations). As with the initial D33454, we use a stash in the 32-bit Primary
to hold those extra regions and return them on the fast-path.
The Windows version of `MmapAlignedOrDie` will always return a 0
`padding_chunk` if one was requested.
Reviewers: alekseyshl, dvyukov, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34152
llvm-svn: 305391
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
GNU version of strerror_r returns a result pointer that doesn't match the input
buffer. The result pointer is in fact a pointer to some internal storage.
TSAN was recording a write to this location, which was incorrect.
Fixed https://github.com/google/sanitizers/issues/696
llvm-svn: 304858
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
Revert "Mark sancov test as unsupported on Darwin"
Revert "[LSan] Detect dynamic loader by its base address."
This reverts commit r304633.
This reverts commit r304673.
This reverts commit r304632.
Those commit have broken LOTS of ARM/AArch64 bots for two days.
llvm-svn: 304699
Summary:
Very recently, FreeBSD 12 has been updated to use 64-bit inode numbers:
<https://svnweb.freebsd.org/changeset/base/318737>. This entails many
user-visible changes, but for the sanitizers the modifications are
limited in scope:
* The `stat` and `lstat` syscalls were removed, and should be replaced
with calls to `fstatat`.
* The `getdents` syscall was removed, and should be replaced with calls
to `getdirentries`.
* The layout of `struct dirent` was changed to accomodate 64-bit inode
numbers, and a new `d_off` field was added.
* The system header <sys/_types.h> now contains a macro `__INO64` to
determine whether the system uses 64-bit inode numbers.
I tested these changes on both FreeBSD 12.0-CURRENT (after r318959,
which adds the `__INO64` macro), and FreeBSD 11.0-STABLE (which still
uses 32-bit inode numbers).
Reviewers: emaste, kcc, vitalybuka, kubamracek
Reviewed By: vitalybuka
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33600
llvm-svn: 304658
Summary:
Whenever possible (Linux + glibc 2.16+), detect dynamic loader module by
its base address, not by the module name matching. The current name
matching approach fails on some configurations.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33859
llvm-svn: 304633
There is can be a situation when vptr is not initializing
by constructor of the object, and has a junk data which should
be properly checked, because c++ standard says:
"if default constructor is not specified
16 (7.3) no initialization is performed."
Patch by Denis Khalikov!
Differential Revision: https://reviews.llvm.org/D33712
llvm-svn: 304437
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:
Currently we are not enforcing the success of `pthread_once`, and
`pthread_setspecific`. Errors could lead to harder to debug issues later in
the thread's life. This adds checks for a 0 return value for both.
If `pthread_setspecific` fails in the teardown path, opt for an immediate
teardown as opposed to a fatal failure.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33555
llvm-svn: 303998
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 required for any users who call exit() after creating
thread-specific data, as tls destructors are only called when
pthread_exit() or pthread_cancel() are used. This should also
match tls behavior on linux.
Getting the base address of the tls section is straightforward,
as it's stored as a section offset in %gs. The size is a bit trickier
to work out, as there doesn't appear to be any official documentation
or source code referring to it. The size used in this patch was determined
by taking the difference between the base address and the address of the
subsequent memory region returned by vm_region_recurse_64, which was
1024 * sizeof(uptr) on all threads except the main thread, where it was
larger. Since the section must be the same size on all of the threads,
1024 * sizeof(uptr) seemed to be a reasonable size to use, barring
a more programtic way to get the size.
1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX
is 512 on darwin, so pthread keys will fit inside the region while
leaving space for other tls data. A larger size would overflow the
memory region returned by vm_region_recurse_64, and a smaller size
wouldn't leave room for all the pthread keys. In addition, the
stress test added here passes, which means that we are scanning at
least the full set of possible pthread keys, and probably
the full tls section.
Reviewers: alekseyshl, kubamracek
Subscribers: krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D33215
llvm-svn: 303887
The existing implementation ran CHECKs to assert that the thread state
was stored inside the tls. However, the mac implementation of tsan doesn't
store the thread state in tls, so these checks fail once darwin tls support
is added to the sanitizers. Only run these checks on platforms where
the thread state is expected to be contained in the tls.
llvm-svn: 303886
Summary:
Apparently Windows's `UnmapOrDie` doesn't support partial unmapping. Which
makes the new region allocation technique not Windows compliant.
Reviewers: alekseyshl, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33554
llvm-svn: 303883
Summary:
Currently, AllocateRegion has a tendency to fragment memory: it allocates
`2*kRegionSize`, and if the memory is aligned, will unmap `kRegionSize` bytes,
thus creating a hole, which can't itself be reused for another region. This
is exacerbated by the fact that if 2 regions get allocated one after another
without any `mmap` in between, the second will be aligned due to mappings
generally being contiguous.
An idea, suggested by @alekseyshl, to prevent such a behavior is to have a
stash of regions: if the `2*kRegionSize` allocation is properly aligned, split
it in two, and stash the second part to be returned next time a region is
requested.
At this point, I thought about a couple of ways to implement this:
- either an `IntrusiveList` of regions candidates, storing `next` at the
begining of the region;
- a small array of regions candidates existing in the Primary.
While the second option is more constrained in terms of size, it offers several
advantages:
- security wise, a pointer in a region candidate could be overflowed into, and
abused when popping an element;
- we do not dirty the first page of the region by storing something in it;
- unless several threads request regions simultaneously from different size
classes, the stash rarely goes above 1 entry.
I am not certain about the Windows impact of this change, as `sanitizer_win.cc`
has its own version of MmapAlignedOrDie, maybe someone could chime in on this.
MmapAlignedOrDie is effectively unused after this change and could be removed
at a later point. I didn't notice any sizeable performance gain, even though we
are saving a few `mmap`/`munmap` syscalls.
Reviewers: alekseyshl, kcc, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33454
llvm-svn: 303879
Summary:
Dmitry, seeking your expertise. I believe, the proper way to implement
Lock/Unlock here would be to use acquire/release semantics. Am I missing
something?
Reviewers: dvyukov
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33521
llvm-svn: 303869
Summary:
In FreeBSD we needed to add generic implementations for `__bswapdi2` and
`__bswapsi2`, since gcc 6.x for mips is emitting calls to these. See:
https://reviews.freebsd.org/D10838 and https://reviews.freebsd.org/rS318601
The actual mips code generated for these generic C versions is pretty
OK, as can be seen in the (FreeBSD) review.
I checked over gcc sources, and it seems that it can emit these calls on
more architectures, so maybe it's best to simply always add them to the
compiler-rt builtins library.
Reviewers: howard.hinnant, compnerd, petarj, emaste
Reviewed By: compnerd, emaste
Subscribers: mgorny, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D33516
llvm-svn: 303866
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
Summary: We are going to make it tri-state and remove allow_user_segv_handler.
Reviewers: eugenis, alekseys, kcc
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D33159
llvm-svn: 303464
Summary:
The LINKEDIT section is very large and is read-only. Scanning this
section caused LSan on darwin to be very slow. When only writable sections
are scanned for global pointers, performance improved by a factor of about 25x.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33322
llvm-svn: 303422
Summary:
After discussing the current defaults with a couple of parties, the consensus
is that they are too high. 1Mb of quarantine has about a 4Mb impact on PSS, so
memory usage goes up quickly.
This is obviously configurable, but the default value should be more
"approachable", so both the global size and the thread local size are 1/4 of
what they used to be.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33321
llvm-svn: 303380
The sanitizer library unit tests for libc can get a different definition
of 'struct stat' to what the sanitizer library is built with for certain
targets.
For MIPS the size element of 'struct stat' is after a macro guarded
explicit padding element.
This patch resolves any possible inconsistency by adding the same
_FILE_OFFSET_BITS=64 and _LARGE_SOURCE with the same
conditions as the sanitizer library to the build flags for the unit tests.
This resolves a recurring build failure on the MIPS buildbots due to
'struct stat' defintion differences.
Reviewers: slthakur
Differential Revision: https://reviews.llvm.org/D33131
llvm-svn: 303350
Kamil Rytarowski