Summary:
Adds a new class, CircularBuffer, for holding a wrap-around fixed-size
sequence of a primitive data type. This will be used initially by the
working set tool.
Adds a unit test for CircularBuffer, including infrastructure support to
include esan headers and to link with the esan library by pretending to
want the working set tool.
Reviewers: aizatsky, filcab
Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits, kubabrecka
Differential Revision: http://reviews.llvm.org/D20579
llvm-svn: 271286
Summary:
Adds iteration of all application memory in an efficient manner using
shadow faults. Shadow memory starts out inaccessible and we mark it
writable one page at a time on each fault when the instrumentation touches
it. This allows iteration over just the mapped shadow memory, saving
significant time.
Adds a process-end iteration and pretty-printing of the final result.
Adds a new test and updates the existing tests.
Reviewers: aizatsky, filcab
Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits, kubabrecka
Differential Revision: http://reviews.llvm.org/D20578
llvm-svn: 271277
Summary:
In preparation for fault-based shadow memory iteration, we add support for
our own signal handler by adding app signal handler interception as well as
chaining for SIGSEGV. This is done in a simple manner: we do not honor the
app's alternate stack nor any sigaction flags for SIGSEGV.
Adds a new test of transparency in app signal handling.
Reviewers: aizatsky
Subscribers: filcab, kubabrecka, vitalybuka, zhaoqin, kcc, eugenis, llvm-commits
Differential Revision: http://reviews.llvm.org/D20577
llvm-svn: 271272
Summary:
Adds detection of large stack size rlimits (over 1 TB or unlimited), which
results in an mmap location that our shadow mapping does not support. We
re-exec the application in this situation. Adds a test of this behavior.
Adds general detection of mmap regions outside of our app regions. In the
future we want to try to adaptively handle these but for now we abort.
Moves the existing Linux-specific mmap code into a platform-specific file
where the new rlimit code lives.
Reviewers: eugenis
Subscribers: vitalybuka, zhaoqin, kcc, aizatsky, llvm-commits, kubabrecka
Differential Revision: http://reviews.llvm.org/D20745
llvm-svn: 271079
It's fixing compilation errors. The runtime is not yet working.
Missing features:
OverrideFunction for x64
an equiv function for inline asm (atomic_compare_exchange_strong)
shadow memory offset needs to be adjusted
RoundUpToInstrBoundary for x64
They will be implemented by subsequent patches.
Patch by Wei Wang.
Differential revision: http://reviews.llvm.org/D20455
llvm-svn: 271049
Fixes an esan workingset-memset test failure by switching to malloc to
avoid a shadow mapping issue with mmap in certain situations that will be
fully fixed separately.
llvm-svn: 270949
Summary:
Adds the base runtime library for the working set tool.
Adds slowpath code for updating the shadow memory.
To be added in the future:
+ Scan memory and report the total size.
+ Take samples for intermediate values.
Reviewers: aizatsky
Subscribers: kubabrecka, vitalybuka, zhaoqin, kcc, eugenis, llvm-commits
Differential Revision: http://reviews.llvm.org/D20485
llvm-svn: 270650
Summary: Adds a new test struct-simple.cpp for testing the
cache-fragmentation tool with a multi-compilation-unit application.
Patch by Qin Zhao.
Reviewers: bruening
Subscribers: kubabrecka, kcc, vitalybuka, eugenis, aizatsky, llvm-commits, zhaoqin
Differential Revision: http://reviews.llvm.org/D20599
llvm-svn: 270631
In one of the already existing apps that I'm testing TSan on, I really see a mutex path that is longer than 10 (but not by much, something like 11-13 actually). Let's raise this to 20 and weaken the assertion so we don't crash.
Differential Revision: http://reviews.llvm.org/D20427
llvm-svn: 270319
Summary:
Adds support for app libraries starting slightly below 0x7f00'00000000 (the
mmap ASLR range extends down to 0x7efb'f8000000 for reasonable stack
limits) by switching to a shadow mapping offset of 0x1300'00000000.
Reviewers: aizatsky
Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits, kubabrecka
Differential Revision: http://reviews.llvm.org/D20479
llvm-svn: 270255
We're missing interceptors for dispatch_after and dispatch_after_f. Let's add them to avoid false positives. Added a test case.
Differential Revision: http://reviews.llvm.org/D20426
llvm-svn: 270071
The ignore_interceptors_accesses setting did not have an effect on mmap, so
let's change that. It helps in cases user code is accessing the memory
written to by mmap when the synchronization is ensured by the code that
does not get rebuilt.
(This effects Swift interoperability since it's runtime is mapping memory
which gets accessed by the code emitted into the Swift application by the
compiler.)
Differential Revision: http://reviews.llvm.org/D20294
llvm-svn: 269855
Fix https://llvm.org/bugs/show_bug.cgi?id=27673.
Currenty ASan checks the return value of real recv/recvfrom to see if the written bytes fit in the buffer. That works fine most of time.
However, there is an exception: (from the RECV(2) man page)
MSG_TRUNC (since Linux 2.2)
... return the real length of the packet or datagram, even when it was longer than the passed buffer. ...
Some programs combine MSG_TRUNC, MSG_PEEK and a single-byte buffer to peek the incoming data size without reading (much of) them. In this case,
the return value is usually longer than what's been written and ASan raises a false alarm here. To avoid such false positive reports,
we can use min(res, len) in COMMON_INTERCEPTOR_WRITE_RANGE checks.
Differential Revision: http://reviews.llvm.org/D20280
llvm-svn: 269749
With this change, dynamic memory allocation is only used
for testing purpose. This change is one of the many steps to
make instrument profiler dynamic allocation free.
llvm-svn: 269453
This is needed for proper operation of the fast unwinder, see the discussion
on D18895.
Differential Revision: http://reviews.llvm.org/D19898
llvm-svn: 269277
Summary:
Adds shadow memory mapping support common to all tools to the new
Efficiencysanitizer ("esan") family of tools. This includes:
+ Shadow memory layout and mapping support for 64-bit Linux for any
power-of-2 scale-down (1x, 2x, 4x, 8x, 16x, etc.) that ensures that
shadow(shadow(address)) does not overlap shadow or application
memory.
+ Mmap interception to ensure the application does not map on top of
our shadow memory.
+ Init-time sanity checks for shadow regions.
+ A test of the mmap conflict mechanism.
Reviewers: aizatsky, filcab
Subscribers: filcab, kubabrecka, llvm-commits, vitalybuka, eugenis, kcc, zhaoqin
Differential Revision: http://reviews.llvm.org/D19921
llvm-svn: 269198
Another stack where we try to free sync objects,
but don't have a processors is:
// ResetRange
// __interceptor_munmap
// __deallocate_stack
// start_thread
// clone
Again, it is a latent bug that lead to memory leaks.
Also, increase amount of memory we scan in MetaMap::ResetRange.
Without that the test does not fail, as we fail to free
the sync objects on stack.
llvm-svn: 269041
Fixes crash reported in:
https://bugs.chromium.org/p/v8/issues/detail?id=4995
The problem is that we don't have a processor in a free interceptor
during thread exit.
The crash was introduced by introduction of Processors.
However, previously we silently leaked memory which wasn't any better.
llvm-svn: 268782
In recovery mode, when ASan detects stack overflow (say, when infinite recursion detected),
it tries to continue program execution and hangs on repetitive error reports. There isn't any
sense to do it, we can just bail out on stack overflow error, because the program would crash soon anyway.
Differential Revision: http://reviews.llvm.org/D19958
llvm-svn: 268713
Summary:
On Windows (already fixed) and FreeBSD we have stacks traces without
operator().
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19427
llvm-svn: 268332
Summary:
Use after scope is not detected if array larger then 8 bytes.
Subscribers: kubabrecka
Differential Revision: http://reviews.llvm.org/D19572
llvm-svn: 268330
This happens on a 64-bit platform that uses SizeClassAllocator32 (e.g. ASan on AArch64). When querying a large invalid pointer, `__sanitizer_get_allocated_size(0xdeadbeefdeadbeef)`, an assertion will fail. This patch changes PointerIsMine to return false if the pointer is outside of [kSpaceBeg, kSpaceBeg + kSpaceSize).
Differential Revision: http://reviews.llvm.org/D15008
llvm-svn: 268243
In http://reviews.llvm.org/D19100, I introduced a bug: On OS X, existing programs rely on malloc_size() to detect whether a pointer comes from heap memory (malloc_size returns non-zero) or not. We have to distinguish between a zero-sized allocation (where we need to return 1 from malloc_size, due to other binary compatibility reasons, see http://reviews.llvm.org/D19100), and pointers that are not returned from malloc at all.
Differential Revision: http://reviews.llvm.org/D19653
llvm-svn: 268157
Summary:
This (partially) implements the check mentioned at
http://kristerw.blogspot.co.uk/2016/04/dangling-pointers-and-undefined-behavior.html
(via John Regehr)
Quoting:
"That the behavior is undefined follows from C11 6.2.4 "Storage
durations of objects"
The lifetime of an object is the portion of program execution during
which storage is guaranteed to be reserved for it. An object exists, has
a constant address, and retains its last-stored value throughout its
lifetime. If an object is referred to outside of its lifetime, the
behavior is undefined. The value of a pointer becomes indeterminate when
the object it points to (or just past) reaches the end of its lifetime.
and 7.22.3 "Memory management functions" that says that free ends the
lifetime of objects
The lifetime of an allocated object extends from the allocation until
the deallocation.
"
We can probably implement this for stack variables too, but I think this
is a good start to see if there's interest in this check.
We can also hide this behind a flag, too.
Reviewers: samsonov, kcc, rsmith, regehr
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D19691
llvm-svn: 268097
On s390*-linux, sigcontext just doesn't contain any information that could
be used to recover the type of access, so there's no way to fix this, short
of emulating the faulting instruction.
Differential Revision: http://reviews.llvm.org/D19655
llvm-svn: 267960
On Darwin, MAP_ANONYMOUS is a synonym for MAP_ANON. However, some SDK's
don't define MAP_ANONYMOUS. Use MAP_ANON to work around this.
(As a point of interest, the situation is exactly reversed on Linux.)
llvm-svn: 267907
Summary:
On windows platform assert() call creates two distinct CFG edges
which are coverage-instrumented. Simply calling assert would
change coverage numbers on the platform.
Subscribers: kubabrecka
Differential Revision: http://reviews.llvm.org/D19514
llvm-svn: 267610
This reverts commit r267477.
It broke our bots that enables the AArch64 backends, it seems that
this code is using a Darwin *X86 specific* field.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267526
This fixes fails in test/msan/dlerror.cc - when real dlerror calls strcmp,
our strcmp interceptor now skips poison checking, since it's called in
interceptor context. Strictly speaking, only the dlerror change is
necessary to fix the fail, but let's also change the other two just in case.
Differential Revision: http://reviews.llvm.org/D19499
llvm-svn: 267486
Summary:
Adds libc interceptors to the runtime library for the new
EfficiencySanitizer ("esan") family of tools. The interceptors cover
the memory operations in most common library calls and will be shared
among all esan tools.
Reviewers: aizatsky
Subscribers: zhaoqin, tberghammer, danalbert, srhines, llvm-commits, vitalybuka, eugenis, kcc
Differential Revision: http://reviews.llvm.org/D19411
llvm-svn: 267293
Fix and enable working stack-use-after-scope tests.
Add more failing tests for the feature, for fix later.
PR27453.
Patch by Vitaly Buka.
llvm-svn: 267084
Summary:
Adds the initial version of a runtime library for the new
EfficiencySanitizer ("esan") family of tools. The library includes:
+ Slowpath code via callouts from the compiler instrumentation for
each memory access.
+ Registration of atexit() to call finalization code.
+ Runtime option flags controlled by the environment variable
ESAN_OPTIONS. The common sanitizer flags are supported such as
verbosity and log_path.
+ An initial simple test.
Still TODO: common code for libc interceptors and shadow memory mapping,
and tool-specific code for shadow state updating.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, vkalintiris, kubabrecka, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19168
llvm-svn: 267060
The field "pid" in ReportThread is used to store the OS-provided thread ID (pthread_self or gettid). The name "pid" suggests it's a process ID, which it isn't. Let's rename it.
Differential Revision: http://reviews.llvm.org/D19365
llvm-svn: 266994
Summary: Test that asan detects access to the dead variable captured by lambda.
Reviewers: aizatsky, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19238
llvm-svn: 266676
At the moment almost every lit.site.cfg.in contains two lines comment:
## Autogenerated by LLVM/Clang configuration.
# Do not edit!
The patch adds variable LIT_SITE_CFG_IN_HEADER, that is replaced from
configure_lit_site_cfg with the note and some useful information.
llvm-svn: 266520
The custom zone implementation for OS X must not return 0 (even for 0-sized allocations). Returning 0 indicates that the pointer doesn't belong to the zone. This can break existing applications. The underlaying allocator allocates 1 byte for 0-sized allocations anyway, so returning 1 in this case is okay.
Differential Revision: http://reviews.llvm.org/D19100
llvm-svn: 266283
With -fsized-deallocation, new[] vs delete mismatch is reported as
new-delete-type-mismatch. This is technically true, but
alloc-dealloc-mismatch describes it better.
llvm-svn: 266246
glibc can use one of 2 layouts for semaphores: architectures that
don't HAVE_64B_ATOMIC use an uint32_t field with semaphore value,
then a private field, then a waiting thread count field - this is
the layout currently assumed by the test. However, HAVE_64B_ATOMIC
arches use a fused uint64_t field that contains the value in low bits
and waiting thread count in high bits, followed by a private field.
This resulted in taking private field from the wrong offset on 64-bit
atomic platforms (the test still passed, but didn't actually test
the private field). On big-endian platforms, this resulted in a fail,
since the first 4 bytes overlay the thread count field, and not
the value field.
Found while porting ASan to s390x.
Patch by Marcin Kościelnicki.
llvm-svn: 265715
On one of our testing machines, we're running the tests under heavy load, and especially in the fork-based TSan tests, we're seeing timeouts when a test uses sleep(10), assuming that calling fork() on another thread will finish sooner than that. This patch removes a timeout and makes another one longer.
Differential Revision: http://reviews.llvm.org/D18476
llvm-svn: 265666
OS X provides atomic functions in libkern/OSAtomic.h. These provide atomic guarantees and they have alternatives which have barrier semantics. This patch adds proper TSan support for the functions from libkern/OSAtomic.h.
Differential Revision: http://reviews.llvm.org/D18500
llvm-svn: 265665
Adding an interceptor with two more release+acquire pairs to avoid false positives with dispatch_apply.
Differential Revision: http://reviews.llvm.org/D18722
llvm-svn: 265662
XPC APIs have async callbacks, and we need some more happen-before edges to avoid false positives. This patch add them, plus a test case (sorry for the long boilerplate code, but XPC just needs all that).
Differential Revision: http://reviews.llvm.org/D18493
llvm-svn: 265661
GCD has APIs for event sources, we need some more release-acquire pairs to avoid false positives in TSan.
Differential Revision: http://reviews.llvm.org/D18515
llvm-svn: 265660
In the interceptor for dispatch_sync, we're currently missing synchronization between the callback and the code *after* the call to dispatch_sync. This patch fixes this by adding an extra release+acquire pair to dispatch_sync() and similar APIs. Added a testcase.
Differential Revision: http://reviews.llvm.org/D18502
llvm-svn: 265659
A little embarrassing, but we're missing the call to FileCheck in several Darwin tests. Let's fix this.
Differential Revision: http://reviews.llvm.org/D18503
llvm-svn: 265658
If we don't create the target, don't try to add it as a dependency.
After r265595, we were only creating the SanitizerLintCheck when
`CMAKE_HOST_UNIX` was true.
CMake was emitting a warning:
The dependency target "SanitizerLintCheck" of target "check-ubsan" does not
exist.
llvm-svn: 265613
Derek Bruening