They are currently still *not* used, "llvm-symbolizer" is still the default symbolizer on OS X.
Reviewed at http://reviews.llvm.org/D6588
llvm-svn: 232026
The problem is that without SA_RESTORER flag, kernel ignores the handler. So tracer actually did not setup any handler.
Add SA_RESTORER flag when setting up handlers.
Add a test that causes SIGSEGV in stoptheworld callback.
Move SignalContext from asan to sanitizer_common to print better diagnostics about signal in the tracer thread.
http://reviews.llvm.org/D8005
llvm-svn: 230978
SuppressionContext is no longer a singleton, shared by all sanitizers,
but a regular class. Each of ASan, LSan, UBSan and TSan now have their
own SuppressionContext, which only parses suppressions specific to
that sanitizer.
"suppressions" flag is moved away from common flags into tool-specific
flags, so the user now may pass
ASAN_OPTIONS=suppressions=asan_supp.txt LSAN_OPIONS=suppressions=lsan_supp.txt
in a single invocation.
llvm-svn: 230026
The new parser is a lot stricter about syntax, reports unrecognized
flags, and will make it easier to implemented some of the planned features.
llvm-svn: 226169
Add CommonFlags::SetDefaults() and CommonFlags::ParseFromString(),
so that this object can be easily tested. Enforce
that ParseCommonFlagsFromString() and SetCommonFlagsDefaults()
work only with singleton CommonFlags, shared across all sanitizer
runtimes.
llvm-svn: 224617
Summary:
Turn "allocator_may_return_null" common flag into an
Allocator::may_return_null bool flag. We want to make sure
that common flags are immutable after initialization. There
are cases when we want to change this flag in the allocator
at runtime: e.g. in unit tests and during ASan activation
on Android.
Test Plan: regression test suite, real-life applications
Reviewers: kcc, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6623
llvm-svn: 224148
Enabling COMPILER_RT_INCLUDE_TESTS and updating tests/sanitizer_allocator_test.cc to remove Allocator64 related tests for MIPS.
Reviewed By: samsonov
llvm-svn: 224101
Extending SuppressionContext to add a HasSuppressionType method that tells whether a certain suppression type is currently used or not. It's a step to implement issue suppressions for ASan, see http://reviews.llvm.org/D6280.
Reviewed at http://reviews.llvm.org/D6443
llvm-svn: 222954
Summary:
This commit introduces function __sanitizer::RenderFrame()
that allows to render the contents of AddressInfo (essentially, symbolized stack frame)
using the custom format string. This function can be used to
implement stack frame formatting for both ThreadSanitizer and
generic StackTrace::Print(), used in another places. This paves the
way towards allowing user to control the format of stack frames,
obtaining them in any format he desires, and/or enforcing the consistent
output from all sanitizers.
Test Plan: compiler-rt test suite
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6140
llvm-svn: 221409
introduce a BufferedStackTrace class, which owns this array.
Summary:
This change splits __sanitizer::StackTrace class into a lightweight
__sanitizer::StackTrace, which doesn't own array of PCs, and BufferedStackTrace,
which owns it. This would allow us to simplify the interface of StackDepot,
and eventually merge __sanitizer::StackTrace with __tsan::StackTrace.
Test Plan: regression test suite.
Reviewers: kcc, dvyukov
Reviewed By: dvyukov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5985
llvm-svn: 220635
__ANDROID__ is a define that comes from the toolchain when building
for Android targets. ANDROID has a different meaning. ANDROID is
defined for _every_ Android build, including those done for host
modules. For host modules, we want to build the regular Linux
sanitizers and builtins, not the one for Android devices. This hasn't
been a problem until now because we only just started building the
sanitizers for the host.
llvm-svn: 220203
This change fixes 2 issues in the fast unwinder from r217079:
* A crash if a frame pointer points below current stack head, but
inside the current thread stack limits. That memory may be
unmapped. A check for this was lost in r217079.
* The last valid stack frame (the first one with an invalid next
frame pointer) is always interpreted as a GCC layout frame. This
results in garbled last PC in the (expected) case when the last
frame has LLVM layout.
llvm-svn: 219683
* Detect Android toolchain target arch and set correct runtime library name.
* Merged a lot of Android and non-Android code paths.
* Android is only supported in standalone build of compiler-rt now.
* Linking lsan-common in ASan-Android (makes lsan annotations work).
* Relying on -fsanitize=address linker flag when building tests (again,
unification with non-Android path).
* Runtime library moved from lib/asan to lib/linux.
llvm-svn: 218605
Summary:
UBSan needs to check if memory snippet it's going to print resides
in addressable memory. Similar check might be helpful in ASan with
dump_instruction_bytes option (see http://reviews.llvm.org/D5167).
Instead of scanning /proc/self/maps manually, delegate this check to
the OS kernel: try to write this memory in a syscall and assume that
memory is inaccessible if the syscall failed (e.g. with EFAULT).
Fixes PR20721.
Test Plan: compiler-rt test suite
Reviewers: eugenis, glider
Reviewed By: glider
Subscribers: emaste, ygribov, llvm-commits, glider, rsmith
Differential Revision: http://reviews.llvm.org/D5253
llvm-svn: 217971
I don't remember that crash on mmap in internal allocator
ever yielded anything useful, only crashes in rare wierd untested situations.
One of the reasons for crash was to catch if tsan starts allocating
clocks using mmap. Tsan does not allocate clocks using internal_alloc anymore.
Solve it once and for all by allowing mmaps.
llvm-svn: 217929
The optimization is two-fold:
First, the algorithm now uses SSE instructions to
handle all 4 shadow slots at once. This makes processing
faster.
Second, if shadow contains the same access, we do not
store the event into trace. This increases effective
trace size, that is, tsan can remember up to 10x more
previous memory accesses.
Perofrmance impact:
Before:
[ OK ] DISABLED_BENCH.Mop8Read (2461 ms)
[ OK ] DISABLED_BENCH.Mop8Write (1836 ms)
After:
[ OK ] DISABLED_BENCH.Mop8Read (1204 ms)
[ OK ] DISABLED_BENCH.Mop8Write (976 ms)
But this measures only fast-path.
On large real applications the speedup is ~20%.
Trace size impact:
On app1:
Memory accesses : 1163265870
Including same : 791312905 (68%)
on app2:
Memory accesses : 166875345
Including same : 150449689 (90%)
90% of filtered events means that trace size is effectively 10x larger.
llvm-svn: 209897
Kuba Brecka