Glob patterns seem unsupported for commands executed by the emulated
shell (LIT_USE_INTERNAL_SHELL=1). Disable the test while that is being
addressed (a workaround such as "cd a-*" also does not work).
llvm-svn: 334719
Summary:
As a follow up to D48142 for Scudo, switch the `SpinMutex` to its static
counterpart, and ensure zero-initialization by memset'ing the whole class.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48148
llvm-svn: 334716
Summary:
Error messages for dlsym used to be stored on the stack, but since
commit 2449ae7b ("ld.so: Introduce struct dl_exception") in glibc 2.27
these are now stored on the heap (and thus use the dlsym alloc pool).
Messages look like "undefined symbol: __isoc99_printf\0/path/to/a.out".
With many missing library functions and long object paths, the pool is
quickly exhausted. Implement a simple mechanism to return freed memory
to the pool (clear it in case it is used for calloc).
Fixes https://github.com/google/sanitizers/issues/957
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D47995
llvm-svn: 334703
In most of systems, this field is a signed type but in some it is an unsigned.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D48118
llvm-svn: 334686
On 32-bit macOS, "_fputs$UNIX2003" is called instead of "fputs" and the
"fgets_fputs" test fails. Apparently previous versions still passed the
test due to the internal implementation calling "strlen", but that does
not seem to be the case with macOS 10.13.3. Fixes r334450.
llvm-svn: 334670
Summary:
These four SpinMutex ctors was the only code executed in the ctor for
the static __asan::Allocator instance (same for the other sanitizers
allocators), which is supposed to be fully linker-initialized.
Also, when the global ctor for this allocator instance is executed,
this instance might already be initialized by __asan_init called from
.preinit_array.
Issue: https://github.com/google/sanitizers/issues/194
Reviewers: morehouse, eugenis, cryptoad
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48142
llvm-svn: 334660
Respect a custom linker path provided by the user if one is present
(otherwise CMAKE_LINKER will have been set to the right value by CMake).
llvm-svn: 334654
Summary:
Move madvise(MADV_NOHUGEPAGE) for the meta shadow memory after the meta
shadow memory is mapped (currently it silently fails with ENOMEM).
Add a diagnostic message to detect similar problems in the future.
Reviewers: dvyukov
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48097
llvm-svn: 334624
When XRay is being built as part of the just built compiler together
with libc++ as part of the runtimes build, we need an explicit
dependency from XRay to libc++ to make sure that the library is
available by the time we start building XRay.
Differential Revision: https://reviews.llvm.org/D48113
llvm-svn: 334575
aarch64/aosp_marlin-userdebug/OPR4.170623.016] builder unexpectedly
failed the fgets test (`assertion "fp" failed`). macOS unexpectedly
passes the fputs test without triggering ASAN.
llvm-svn: 334558
For paths without "%t" inside uniqueness is not guaranteed, and
potential collisions might be present.
Differential Revision: https://reviews.llvm.org/D47288
llvm-svn: 334546
Provide a buffer that the test harness can write into to provide
values for the environment variables. Format is a null-separated list
of VAR=value pairs; this is sufficent for our purpose.
Differential Revision: https://reviews.llvm.org/D47960
llvm-svn: 334522
Handling differently the iterations with the type limit and eventually an error message.
Reviewers: morehouse, kcc
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D47880
llvm-svn: 334510
Summary:
This CL adds support for aligned new/delete operators (C++17). Currently we
do not support alignment inconsistency detection on deallocation, as this
requires a header change, but the APIs are introduced and are functional.
Add a smoke test for the aligned version of the operators.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48031
llvm-svn: 334505
Summary:
This is part of the larger XRay Profiling Mode effort.
This patch implements the profile writing mechanism, to allow profiles
collected through the profiler mode to be persisted to files.
Follow-on patches would allow us to load these profiles and start
converting/analysing them through the `llvm-xray` tool.
Depends on D44620.
Reviewers: echristo, kpw, pelikan
Reviewed By: kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45998
llvm-svn: 334472
Summary:
This is part of the larger XRay Profiling Mode effort.
This patch implements the wiring required to enable us to actually
select the `xray-profiling` mode, and install the handlers to start
measuring the time and frequency of the function calls in call stacks.
The current way to get the profile information is by working with the
XRay API to `__xray_process_buffers(...)`.
In subsequent changes we'll implement profile saving to files, similar
to how the FDR and basic modes operate, as well as means for converting
this format into those that can be loaded/visualised as flame graphs. We
will also be extending the accounting tool in LLVM to support
stack-based function call accounting.
We also continue with the implementation to support building small
histograms of latencies for the `FunctionCallTrie::Node` type, to allow
us to actually approximate the distribution of latencies per function.
Depends on D45758 and D46998.
Reviewers: eizan, kpw, pelikan
Reviewed By: kpw
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D44620
llvm-svn: 334469
Summary:
With Android/Bionic, delay deallocation to round 2 of 4. It must run after
C++ thread_local destructors have been called, but before the final 2
rounds, because emutls calls free, and jemalloc then needs another 2
rounds to free its thread-specific data.
Fixes https://github.com/android-ndk/ndk/issues/687
Reviewers: cmtice, srhines, jyknight, chh, echristo
Reviewed By: srhines, chh, echristo
Subscribers: echristo, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D46978
llvm-svn: 334463
Summary:
Add fgets, fputs and puts to sanitizer_common. This adds ASAN coverage
for these functions, extends MSAN support from fgets to fputs/puts and
extends TSAN support from puts to fputs.
Fixes: https://github.com/google/sanitizers/issues/952
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D46545
llvm-svn: 334450
Summary:
Add allocator_returns_null.cc test to sanitizer_common and
remove all sanitizer-specific ones except:
- HWASan is not covered by sanitizer_common
- TSan allocator does not have comprehensive error reporting yet
Reviewers: vitalybuka
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D47971
llvm-svn: 334433
Summary:
Now all sanitizers with improved allocator error reporting are covered
by these common tests.
Also, add pvalloc-specific checks to LSan.
HWASan is not covered by sanitizer_common, hence its own pvalloc
and other allocator tests.
Reviewers: vitalybuka
Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D47970
llvm-svn: 334424
Summary:
The shared TSD model in its current form doesn't scale. Here is an example of
rpc2-benchmark (with default parameters, which is threading heavy) on a 72-core
machines (defaulting to a `CompactSizeClassMap` and no Quarantine):
- with tcmalloc: 337K reqs/sec, peak RSS of 338MB;
- with scudo (exclusive): 321K reqs/sec, peak RSS of 637MB;
- with scudo (shared): 241K reqs/sec, peak RSS of 324MB.
This isn't great, since the exclusive model uses a lot of memory, while the
shared model doesn't even come close to be competitive.
This is mostly due to the fact that we are consistently scanning the TSD pool
starting at index 0 for an available TSD, which can result in a lot of failed
lock attempts, and touching some memory that needs not be touched.
This CL attempts to make things better in most situations:
- first, use a thread local variable on Linux (intead of pthread APIs) to store
the current TSD in the shared model;
- move the locking boolean out of the TSD: this allows the compiler to use a
register and potentially optimize out a branch instead of reading it from the
TSD everytime (we also save a tiny bit of memory per TSD);
- 64-bit atomic operations on 32-bit ARM platforms happen to be expensive: so
store the `Precedence` in a `uptr` instead of a `u64`. We lose some
nanoseconds of precision and we'll wrap around at some point, but the benefit
is worth it;
- change a `CHECK` to a `DCHECK`: this should never happen, but if something is
ever terribly wrong, we'll crash on a near null AV if the TSD happens to be
null;
- based on an idea by dvyukov@, we are implementing a bound random scan for
an available TSD. This requires computing the coprimes for the number of TSDs,
and attempting to lock up to 4 TSDs in an random order before falling back to
the current one. This is obviously slightly more expansive when we have just
2 TSDs (barely noticeable) but is otherwise beneficial. The `Precedence` still
basically corresponds to the moment of the first contention on a TSD. To seed
on random choice, we use the precedence of the current TSD since it is very
likely to be non-zero (since we are in the slow path after a failed `tryLock`)
With those modifications, the benchmark yields to:
- with scudo (shared): 330K reqs/sec, peak RSS of 327MB.
So the shared model for this specific situation not only becomes competitive but
outperforms the exclusive model. I experimented with some values greater than 4
for the number of TSDs to attempt to lock and it yielded a decrease in QPS. Just
sticking with the current TSD is also a tad slower. Numbers on platforms with
less cores (eg: Android) remain similar.
Reviewers: alekseyshl, dvyukov, javed.absar
Reviewed By: alekseyshl, dvyukov
Subscribers: srhines, kristof.beyls, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D47289
llvm-svn: 334410
Summary:
Running sanitized 32-bit x86 programs on glibc 2.27 crashes at startup, with:
ERROR: AddressSanitizer: SEGV on unknown address 0xf7a8a250 (pc 0xf7f807f4 bp 0xff969fc8 sp 0xff969f7c T16777215)
The signal is caused by a WRITE memory access.
#0 0xf7f807f3 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x127f3)
#1 0xf7a92599 (/lib/libasan.so.5+0x112599)
#2 0xf7a80737 (/lib/libasan.so.5+0x100737)
#3 0xf7f7e14f in _dl_init (/lib/ld-linux.so.2+0x1014f)
#4 0xf7f6eb49 (/lib/ld-linux.so.2+0xb49)
The problem is that glibc changed the calling convention for the GLIBC_PRIVATE
symbol that sanitizer uses (even when it should not, GLIBC_PRIVATE is exactly
for symbols that can change at any time, be removed etc.), see
https://sourceware.org/ml/libc-alpha/2017-08/msg00497.html
Fixes https://github.com/google/sanitizers/issues/954
Patch By: Jakub Jelinek
Reviewed By: vitalybuka, Lekensteyn
Differential Revison: https://reviews.llvm.org/D44623
llvm-svn: 334363
Summary:
Following up on and complementing D44404.
Currently many allocator specific errors (OOM, for example) are reported as
a text message and CHECK(0) termination, not stack, no details, not too
helpful nor informative. To improve the situation, detailed and
structured errors were defined and reported under the appropriate conditions.
Reviewers: eugenis
Subscribers: srhines, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D47793
llvm-svn: 334338
Summary:
Move the corresponding tests to the common folder (as all of the
sanitizer allocators will support this feature soon) and add the checks
specific to aligned_alloc to ASan and LSan allocators.
Reviewers: vitalybuka
Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D47924
llvm-svn: 334316
This change uses 'const' for the retryingWriteAll(...) API and removes
unnecessary 'static' local variables in getting the temporary filename.
llvm-svn: 334267
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
Summary:
Currently many allocator specific errors (OOM, for example) are reported as
a text message and CHECK(0) termination, not stack, no details, not too
helpful nor informative. To improve the situation, detailed and
structured errors were defined and reported under the appropriate conditions.
Reviewers: eugenis
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D47798
llvm-svn: 334248
Summary: Otherwise we print things like [0/1] which is visually confusing.
Reviewers: kcc
Reviewed By: kcc
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D47837
llvm-svn: 334234
When building the dylib, the C++ headers are fundamentally non-module.
They require special versions of the headers in order to provide C++03 and
legacy ABI definitions. This causes ODR issues when modules are enabled
during both the build and the usage of the libc++ headers.
This patch fixes the build error by disabling modules when building the
libc++ sources.
llvm-svn: 334220
-z,defs is incompatible with sanitizers so we need to filter it out
from the linker flags before passing them to the libc++ build.
Differential Revision: https://reviews.llvm.org/D47865
llvm-svn: 334212
Summary:
signal(3) on NetBSD calls internally sigaction(2).
Without disabling the recursive interceptor, there are
false positives about uninitialized memory reads inside libc.
This change fixes execution of such programs as sh(1) and
vmstat(1) in the NetBSD userland.
Sponsored by <The NetBSD Foundation>
Reviewers: eugenis, vitalybuka, joerg
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D47650
llvm-svn: 334168
Peter Wu