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
Summary:
TestCases/Linux/heavy_uar_test.cc was failing on my
PowerPC64 box with GCC 4.8.2, because the compiler recognised
a memset-like loop and turned it into a call to memset, which
got intercepted by __asan_memset, which got upset because it was
being called on an address in high shadow memory.
Use break_optimization to stop the compiler from doing this.
Reviewers: kcc, samsonov
Reviewed By: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6266
llvm-svn: 222572
Let the users of SymbolizationLoop define a function that produces the list of .dSYM hints (possible path to the .dSYM bundle) for the given binary.
Because the hints can't be added to an existing llvm-symbolizer process, we spawn a new symbolizer process ones each time a new hint appears.
Those can only appear for binaries that we haven't seen before.
llvm-svn: 222535
Reviewed at http://reviews.llvm.org/D6238
ASan on Darwin during launch reads DYLD_INSERT_LIBRARIES env. variable and if it's not set or if the ASan dylib is not present in there, it relaunches the process. The check whether the dylib is present in the variable is now trying to find a full path in there. This fails in the scenarios where we want to copy the dylib to the executable's directory or somewhere else and set the DYLD_INSERT_LIBRARIES manually, see http://reviews.llvm.org/D6018.
Let's change the search in DYLD_INSERT_LIBRARIES to only look for the filename of the dylib and not the full path.
llvm-svn: 222297
MSanDR is a dynamic instrumentation tool that can instrument the code
(prebuilt libraries and such) that could not be instrumented at compile time.
This code is unused (to the best of our knowledge) and unmaintained, and
starting to bit-rot.
llvm-svn: 222232
Summary:
AsanOnSIGSEGV has some heuristics for detecting stack overflow, but
they don't cope with a PowerPC store-with-update instruction which
modifies sp and stores to the modified address in one instruction.
This patch adds some PowerPC-specific code to check for this case.
This fixes the last few cases of the stack-overflow test.
Reviewers: kcc, samsonov, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6253
llvm-svn: 222001
Summary:
The option -asan-instrument-assembly is declared in the X86 backend.
If I test on PowerPC configured with LLVM_TARGETS_TO_BUILD=All then the
option is tolerated but ignored.
If I test on PowerPC configured with LLVM_TARGETS_TO_BUILD=PowerPC then
the testsuite fails with:
[ 93%] Generating ASAN_INST_TEST_OBJECTS.gtest-all.cc.powerpc64-inline.o
clang (LLVM option parsing): Unknown command line argument '-asan-instrument-assembly'. Try: 'clang (LLVM option parsing) -help'
Fix this inconsistency by only adding the option if that toolchain was
built with the X86 backend included.
Reviewers: kcc, samsonov, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6190
llvm-svn: 221687
Summary:
Tweak the asan stack overflow heuristics to cope with PowerPC64 redzones,
which are larger than on x86-64: 288 bytes for big-endian and 512 bytes
for little-endian.
Reviewers: kcc, willschm, samsonov, eugenis
Reviewed By: samsonov, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6168
llvm-svn: 221578
for both PPC64 Big and Little endian modes, so also eliminates the need for
the BIG_ENDIAN/LITTLE_ENDIAN #ifdeffery.
By trial and error, it also looks like the kPPC64_ShadowOffset64 value is
valid using (1ULL << 41) for both BE and LE, so that #if/#elif/#endif block
has also been simplified.
Differential Revision: http://reviews.llvm.org/D6044
llvm-svn: 221457
Change the LC_ID_DYLIB of ASan's dynamic libraries on OS X to be set to "@rpath/libclang_rt.asan_osx_dynamic.dylib" and similarly for iossim. Clang driver then sets the "-rpath" to be the real path to where clang currently has the dylib (because clang uses the relative path to its current executable). This means if you move the compiler or install the binary release, -fsanitize=address will link to the proper library.
Reviewed at http://reviews.llvm.org/D6018
llvm-svn: 221278
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
Whitespace update for lint check by myself (Will). Otherwise code and comments by Peter Bergner, as previously seen on llvm-commits.
The following patch gets ASAN somewhat working on powerpc64le-linux.
It currently assumes the LE kernel uses 46-bit addressing, which is
true, but it doesn't solve the case for BE where it may be 44 or
46 bits. That can be fixed with a follow on patch.
There are some test suite fails even with this patch that I haven't had
time to solve yet, but this is better than the state it is in now.
The limited debugging of those test suite fails seems to show that the
address map for 46-bit addressing has changed and so we'll need to
modify the shadow memory location slightly. Again, that can be fixed
with a follow on patch.
llvm-svn: 219827
Updated the URL to reflect information on the problem as well as build the
case for ARM. This seems to be a wider problem, not ARM or PPC specific.
llvm-svn: 219680
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
Summary:
Fix the function that gets stack frame description by address in
thread stack, so that it clearly indicates failures. Make this error non-fatal,
and print as much information as we can in this case. Make all errors in
ParseFrameDescription non-fatal.
Test Plan: check-asan testsuite
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5554
llvm-svn: 218819
This is needed so we can produce -i686- named libraries for
x86 Android (which is i686-linux-android).
An alternative solution would be keeping the "i386" name internally and
tweaking the OUTPUT_NAME of compiler-rt libraries.
llvm-svn: 218761
* 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
Reviewed at http://reviews.llvm.org/D4527
Fixed a test case failure on 32-bit Linux, I did right shift on intptr_t, instead it should have been uintptr_t.
llvm-svn: 218538
Reviewed at http://reviews.llvm.org/D4527
This patch is part of an effort to implement a more generic debugging API, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074656.html, with first part reviewed at http://reviews.llvm.org/D4466. Now adding several new APIs: __asan_report_present, __asan_get_report_{pc,bp,sp,address,type,size,description}, __asan_locate_address. These return whether an asan report happened yet, the PC, BP, SP, address, access type (read/write), access size and bug description (e.g. "heap-use-after-free"), __asan_locate_address takes a pointer and tries to locate it, i.e. say whether it is a heap pointer, a global or a stack, or whether it's a pointer into the shadow memory. If global or stack, tries to also return the variable name, address and size. If heap, tries to return the chunk address and size. Generally these should serve as an alternative to "asan_describe_address", which only returns all the data in text form. Having an API to get these data could allow having debugging scripts/extensions that could show additional information about a variable/expression/pointer. Test cases in test/asan/TestCases/debug_locate.cc and test/asan/TestCasea/debug_report.cc.
llvm-svn: 218481
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
* Allow user SEGV handler if Android-L-like setup is detected.
Necessary for correctness.
* Change file context labels on the wrapper script to appease SELinux.
llvm-svn: 218124
Summary:
These two functions are unavailable on MSVC2012, which breaks building the
ASAN tests with MSVC2012. Since the tests required to run these functions
are disabled on Windows for now, avoid building them to fix the MSVC2012
builds.
Test Plan: This is needed in order to fix building the ASAN tests with MSVC2012.
Reviewers: timurrrr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5343
llvm-svn: 217763
It turned out that we have to bridge more stuff between the executable
and the ASan RTL DLL than just __asan_option_detect_stack_use_after_return.
See PR20918 for more details.
llvm-svn: 217673
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
There is no reason to have different library names for shared and static
cases on linux. It also breaks Android where we install the shared asan-rt
library into the system and should keep the old name.
This change reverts most of r216380 limiting it to win32 targets only.
llvm-svn: 216533
With this patch, "check-asan" passes all the tests with both MT and MD ASan RTL if you set COMPILER_RT_BUILD_SHARED_ASAN to ON
(PR20214)
llvm-svn: 216447
At least check-asan works with this change.
If the change breaks anything, we'll need to add:
a) a comment describing why we have to use INTERCEPT_FUNCTION rather than
ASAN_INTERCEPT_FUNC
and
b) a test case.
llvm-svn: 216177
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
The patch adds new features in asan-symbolizer script which are helpful for using ASan on embedded systems:
1) add cross-compile prefix for binutils
2) define path to sysroot with sanitized binaries
Features are enabled by command line options.
The patch also extends command line interface with help option.
Reviewed in http://reviews.llvm.org/D4703.
Patch by Maria Guseva!
llvm-svn: 215381
Instead of creating global variables for source locations and global names,
just create metadata nodes and strings. They will be transformed into actual
globals in the instrumentation pass (if necessary). This approach is more
flexible:
1) we don't have to ensure that our custom globals survive all the optimizations
2) if globals are discarded for some reason, we will simply ignore metadata for them
and won't have to erase corresponding globals
3) metadata for source locations can be reused for other purposes: e.g. we may
attach source location metadata to alloca instructions and provide better descriptions
for stack variables in ASan error reports.
No functionality change.
llvm-svn: 214604
Summary:
This is required for linking DLLs with large functions exceeding
san-instrumentation-with-call-threshold. One such function is
vp9_fdct16x16_sse2 in libvpx.
Reviewers: timurrrr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D4758
llvm-svn: 214532
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
Get rid of ASAN_USE_PREINIT_ARRAY and LSAN_USE_PREINIT_ARRAY - just always
use .preinit_array if it's available. This mode seems stable enough, and
we've been relying on default values of these macro for a long time.
llvm-svn: 213980
Format of __libc_malloc_dispatch has changed in Android L.
While we are moving towards a solution that does not depend on bionic
internals, here is something to support both K* and L releases.
llvm-svn: 213263
This fixes '___asan_init_v4 already defined' errors when linking some of Chromium DLLs.
Looks like one of the DLL is using a .lib produced while linking another DLL and it exploded after r212699.
I'm trying to come up with a small testcase...
llvm-svn: 212815
Introduce new public header <sanitizer/allocator_interface.h> and a set
of functions __sanitizer_get_ownership(), __sanitizer_malloc_hook() etc.
that will eventually replace their tool-specific equivalents
(__asan_get_ownership(), __msan_get_ownership() etc.). Tool-specific
functions are now deprecated and implemented as stubs redirecting
to __sanitizer_ versions (which are implemented differently in each tool).
Replace all uses of __xsan_ versions with __sanitizer_ versions in unit
and lit tests.
llvm-svn: 212469
Large part of this change is required due to
https://code.google.com/p/android/issues/detail?id=61799
dlsym() crashes when symbol resolution fails, which means
we have to limit the interceptor list instead of relying on
runtime detection.
There are minor differencies in system headers, too.
llvm-svn: 212273
See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the
original feature request.
Introduce llvm.asan.globals metadata, which Clang (or any other frontend)
may use to report extra information about global variables to ASan
instrumentation pass in the backend. This metadata replaces
llvm.asan.dynamically_initialized_globals that was used to detect init-order
bugs. llvm.asan.globals contains the following data for each global:
1) source location (file/line/column info);
2) whether it is dynamically initialized;
3) whether it is blacklisted (shouldn't be instrumented).
Source location data is then emitted in the binary and can be picked up
by ASan runtime in case it needs to print error report involving some global.
For example:
0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40
These source locations are printed even if the binary doesn't have any
debug info.
This is an ABI-breaking change. ASan initialization is renamed to
__asan_init_v4(). Pre-built libraries compiled with older Clang will not work
with the fresh runtime.
llvm-svn: 212188
Reset coverage data on fork().
For memory-mapped mode (coverage_direct=1) this helps avoid loss of data
(before this change two processes would write to the same file simultaneously).
For normal mode, this reduces coverage dump size, because PCs from the parent
process are no longer inherited by the child.
llvm-svn: 210180
This way does not require a __sanitizer_cov_dump() call. That's
important on Android, where apps can be killed at arbitrary time.
We write raw PCs to disk instead of module offsets; we also write
memory layout to a separate file. This increases dump size by the
factor of 2 on 64-bit systems.
llvm-svn: 209653
Generalize StackDepot and create a new specialized instance of it to
efficiently (i.e. without duplicating stack trace data) store the
origin history tree.
This reduces memory usage for chained origins roughly by an order of
magnitude.
Most importantly, this new design allows us to put two limits on
stored history data (exposed in MSAN_OPTIONS) that help avoid
exponential growth in used memory on certain workloads.
See comments in lib/msan/msan_origin.h for more details.
llvm-svn: 209284
This change also enables asm instrumentation in asan tests that was
accidentally disabled yearlier, and adds a sanity test for that.
Patch by Yuri Gorshenin.
llvm-svn: 209282
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
Interceptors don't really work on OSX in asan_noinst_test.cc (this is more or less intentional),
so one shouldn't call intercepted functions in this test -- added a comment about this.
llvm-svn: 206477
Soon there will be an option to build compiler-rt parts as shared libraries
on Linux. Extracted from http://llvm-reviews.chandlerc.com/D3042
by Yuri Gribov.
llvm-svn: 205183
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
Summary:
We don't need to do any work in this case - just take
the current PC and caller PC.
Reviewers: eugenis, ygribov
Reviewed By: eugenis
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2936
llvm-svn: 202845
asan_device_setup is a utility that prepares a device to run code built with
ASan. Essentially, it installs ASan runtime library into the system. For this
reason, it has to be at a predictable relative path from the runtime library
itself. We also plan to distribute this utility, packaged with runtime library
and maybe llvm-symbolizer, to the users.
llvm-svn: 202362
Sergey Matveev