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:
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: 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
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
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
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
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
Summary:
There are cases when thread local quarantine drains almost empty
quarantine batches into the global quarantine. The current approach leaves
them almost empty, which might create a huge memory overhead (each batch
is 4K/8K, depends on bitness).
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28068
llvm-svn: 292525
Summary:
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
This patch starts passing architecture information about a module to llvm-symbolizer and into text reports. This fixes the longstanding x86_64/x86_64h mismatch issue on Darwin.
Differential Revision: https://reviews.llvm.org/D27390
llvm-svn: 291287
When we enumerate loaded modules, we only track the module name and base address, which then has several problems on macOS. Dylibs and executables often have several architecture slices and not storing which architecture/UUID is actually loaded creates problems with symbolication: A file path + offset isn't enough to correctly symbolicate, since the offset can be valid in multiple slices. This is especially common for Haswell+ X86_64 machines, where x86_64h slices are preferred, but if one is not available, a regular x86_64 is loaded instead. But the same issue exists for i386 vs. x86_64 as well.
This patch adds tracking of arch and UUID for each LoadedModule. At this point, this information isn't used in reports, but this is the first step. The goal is to correctly identify which slice is loaded in symbolication, and also to output this information in reports so that we can tell which exact slices were loaded in post-mortem analysis.
Differential Revision: https://reviews.llvm.org/D26632
llvm-svn: 288537
Summary:
In order to avoid starting a separate thread to return unused memory to
the system (the thread interferes with process startup on Android,
Zygota waits for all threads to exit before fork, but this thread never
exits), try to return it right after free.
Reviewers: eugenis
Subscribers: cryptoad, filcab, danalbert, kubabrecka, llvm-commits
Patch by Aleksey Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D27003
llvm-svn: 288091
Summary: The new name better corresponds to its logic.
Reviewers: kcc
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D26821
llvm-svn: 287377
Looks like we are missing these flags only in tsan and sanitizer-common.
This results in linker warnings in some settings as it can cause the Unit
tests to be built with a different SDK version than that was used to build
the runtime. For example, we are not setting the minimal deployment target
on the tests but are setting the minimal deployment target for the sanitizer
library, which leads to the following warning on some bots: ld: warning:
object file (sanitizer_posix_test.cc.i386.o) was built for newer OSX version
(10.12) than being linked (10.11).
Differential Revision: https://reviews.llvm.org/D25860https://reviews.llvm.org/D25352
llvm-svn: 285255
The definitions in sanitizer_common may conflict with definitions from system headers because:
The runtime includes the system headers after the project headers (as per LLVM coding guidelines).
lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT
This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry.
Differential Revision: https://reviews.llvm.org/D21947
llvm-svn: 281657
These got out of sync and the tests were failing for me locally. We
assume a 47 bit address space in ASan, so we should do the same in the
tests.
llvm-svn: 281622
Summary:
The sanitizer allocators can works with a dynamic address space
(i.e. specified with ~0ULL).
Unfortunately, the code was broken on GetMetadata and GetChunkIdx.
The current patch is moving the Win64 memory test to a dynamic
address space. There is a migration to move every concept to a
dynamic address space on windows.
To have a better coverage, the unittest are now testing
dynamic address space on other platforms too.
Reviewers: rnk, kcc
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23170
llvm-svn: 277745
Summary:
Due to a QoI issuse in FreeBSD's libcxxrt-based demangler, one sanitizer
symbolizer test consistently appears to fail:
Value of: DemangleSwiftAndCXX("foo")
Actual: "float"
Expected: "foo"
This is because libcxxrt's __cxa_demangle() incorrectly demangles the "foo"
identifier to "float". It should return an error instead.
For now, XFAIL this particular test for FreeBSD, until we can fix libcxxrt
properly (which might take some time to coordinate with upstream).
Reviewers: rnk, zaks.anna, emaste
Subscribers: emaste, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23001
llvm-svn: 277297
This test attempts to allocate 100 512MB aligned pages of memory. This
is implemented in the usual way by allocating size + alignment bytes and
aligning the result. As a result, this test allocates 51.2GB of memory.
Windows allocates swap for all memory allocated, and our bots do not
have this much swap available.
Avoid the failure by using a more reasonable alignment, like 16MB, as we
do on 32-bit.
llvm-svn: 276779
Add a %stdcxx11 lit substitution for -std=c++11. Windows defaults to
-std=c++14 when VS 2015 is used because the STL requires it. Harcoding
-std=c++11 in the ASan tests actually downgrades the C++ standard level,
leading to test failures.
Relax a FileCheck pattern in use-after-scope-types.cc.
Disable the sanitizer_common OOM tests. They fail on bots with low swap,
and cause other concurrently running tests to OOM.
llvm-svn: 276454
Kostya Kortchinsky