This is a re-commit of r224838 + r224839, previously reverted in r224850.
Test failures were likely (still can not reproduce) caused by two lit tests
using the same name for an intermediate build target.
llvm-svn: 224853
Now ASan deactivation doesn't modify common or ASan-specific runtime
flags. Flags stay constant after initialization, and "deactivation"
instead stashes initialized runtime state, and deactivates the
runtime. Activation then just restores the original state (possibly,
overriden by some activation flags provided in system property on
Android).
llvm-svn: 224614
Summary:
Reduce the dependency of allocator code on runtime flags. Instead,
pass a bunch of options that configure allocator behavior at
initialization or re-initialization. That would allow us to
cleaner modify allocator behavior during a program execution
when ASan is activated or de-activated.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: llvm-commits, eugenis
Differential Revision: http://reviews.llvm.org/D6711
llvm-svn: 224605
SetCanPoisonMemory()/CanPoisonMemory() functions are now used
instead of "poison_heap" flag to determine if ASan is allowed
to poison the shadow memory. This allows to hot-patch this
value in runtime (e.g. during ASan activation) without introducing
a data race.
llvm-svn: 224395
Summary:
Introduce __asan::malloc_context_size atomic that is used to determine
required malloc/free stack trace size. It is initialized with
common_flags()->malloc_context_size flag, but can later be overwritten
at runtime (e.g. when ASan is activated / deactivated).
Test Plan: regression test suite
Reviewers: kcc, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6645
llvm-svn: 224305
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
In the current scheme of things, the call to ThreadStart() in the child
thread is not synchronized with the parent thread. So, if a pointer is passed to
pthread_create, there may be a window of time during which this pointer will not
be discoverable by LSan. I.e. the pthread_create interceptor has already
returneed and thus the pointer is no longer on the parent stack, but we don't
yet know the location of the child stack. This has caused bogus leak reports
(see http://llvm.org/bugs/show_bug.cgi?id=21621/).
This patch makes the pthread_create interceptor wait until the child thread is
properly registered before returning.
llvm-svn: 223419
Allows to specify the unwinder to use for CHECK failures. Previous behaviour
was to use the "fatal" unwinder.
As compiler-rt is built without frame pointers, only the slow unwinder
really makes sense here, and it is the default.
llvm-svn: 219677
When dump_instruction_bytes=1 and the instruction pointer doesn't point to the zero page, ASan prints 16 bytes starting at the instruction point.
llvm-svn: 218243
We may as well just use Symbolizer::GetOrInit() in all the cases.
Don't call Symbolizer::Get() early in tools initialization: these days
it doesn't do any important setup work, and we may as well create the
symbolizer the first time it's actually needed.
llvm-svn: 217558
another sanitizer.
A user may run both LSan and LSan+ASan. It is weird to pass path to leak
suppression file (or other common sanitizer flags, like "verbosity") in
"LSAN_OPTIONS" in the first case and in "ASAN_OPTIONS" in the second case.
llvm-svn: 215949
Get rid of Symbolizer::Init(path_to_external) in favor of
thread-safe Symbolizer::GetOrInit(), and use the latter version
everywhere. Implicitly depend on the value of external_symbolizer_path
runtime flag instead of passing it around manually.
No functionality change.
llvm-svn: 214005
asan_cxx containts replacements for new/delete operators, and should
only be linked in C++ mode. We plan to start building this part
with exception support to make new more standard-compliant.
See https://code.google.com/p/address-sanitizer/issues/detail?id=295
for more details.
llvm-svn: 208609
Extend ParseFlag to accept the |description| parameter, add dummy values for all existing flags.
As the flags are parsed their descriptions are stored in a global linked list.
The tool can later call __sanitizer::PrintFlagDescriptions() to dump all the flag names and their descriptions.
Add the 'help' flag and make ASan, TSan and MSan print the flags if 'help' is set to 1.
llvm-svn: 204339
Because of the way Bionic sets up signal stack frames, libc unwinder is unable
to step through it, resulting in broken SEGV stack traces.
Luckily, libcorkscrew.so on Android implements an unwinder that can start with
a signal context, thus sidestepping the issue.
llvm-svn: 201151
This change is a part of refactoring intended to have common signal handling behavior in all tools.
This particular CL moves InstallSignalHandlers() into sanitizer_common (making it InstallDeadlySignalHandlers()), but doesn't enable default signal handlers for any tool other than ASan.
llvm-svn: 200542
This change adds ASAN_OPTIONS=start_deactivated=1 flag. When present, ASan will
start in "deactivated" mode, with no heap poisoning, no quarantine, no stack
trace gathering, and minimal redzones. All this features come back when
__asan_init is called for the constructor of an instrumented library.
The primary use case for this feature is Android. Code itself is not
Android-specific, and this patch includes a Linux test for it.
llvm-svn: 199377
I still don't know what is causing our bootstrapped LTO buildbots to fail,
but llvm r194701 seems to be OK and I can't imagine that these changes could
cause the problem.
llvm-svn: 194790
Apple's bootstrapped LTO builds have been failing, and these changes (along
with llvm 194701) are the only things on the blamelist. I will either reapply
these changes or help debug the problem, depending on whether this fixes the
buildbots.
llvm-svn: 194779
This moves away from creating the symbolizer object and initializing the
external symbolizer as separate steps. Those steps now always take place
together.
Sanitizers with a legacy requirement to specify their own symbolizer path
should use InitSymbolizer to initialize the symbolizer with the desired
path, and GetSymbolizer to access the symbolizer. Sanitizers with no
such requirement (e.g. UBSan) can use GetOrInitSymbolizer with no need for
initialization.
The symbolizer interface has been made thread-safe (as far as I can
tell) by protecting its member functions with mutexes.
Finally, the symbolizer interface no longer relies on weak externals, the
introduction of which was probably a mistake on my part.
Differential Revision: http://llvm-reviews.chandlerc.com/D1985
llvm-svn: 193448
Call AsanThread::Destroy() from a late-running TSD destructor.
Previously we called it before any user-registered TSD destructors, which caused
false positives in LeakSanitizer.
llvm-svn: 192585
We needed a way to tell LSan to invoke leak checking only if __do_leak_check()
is called explicitly. This can now be achieved by setting
leak_check_at_exit=false.
llvm-svn: 187578
Evgeniy Stepanov