By attaching an extra integer tag to heap origins, we are able
to distinguish between uninits
- created by heap allocation,
- created by heap deallocation (i.e. use-after-free),
- created by __msan_allocated_memory call,
- etc.
See https://code.google.com/p/memory-sanitizer/issues/detail?id=35.
llvm-svn: 226821
Fixes 2 issues in origins arising from realloc() calls:
* In the in-place grow case origin for the new memory is not set at all.
* In the copy-realloc case __msan_memcpy is used, which unwinds stack from
inside the MSan runtime. This does not generally work (as we may be built
w/o frame pointers), and produces "bad" stack trace anyway, with several
uninteresting (internal) frames on top.
This change also makes realloc() honor "zeroise" and "poison_in_malloc" flags.
See https://code.google.com/p/memory-sanitizer/issues/detail?id=73.
llvm-svn: 226674
Even sleep(1) lead to episodical flakes on some machines.
Use an invisible by tsan barrier to enforce required execution order instead.
This makes the tests deterministic and faster.
llvm-svn: 226659
Previously we always stored 4 bytes of origin at the destination address
even for 8-byte (and longer) stores.
This should fix rare missing, or incorrect, origin stacks in MSan reports.
llvm-svn: 226658
MemoryAccess function consumes ~4K of stack in debug mode,
in significant part due to the unrolled loop.
And gtest gives only 4K of stack to death test
threads, which causes stack overflows in debug mode.
llvm-svn: 226644
aarch64-linux kernel has configurable 39, 42 or 47 bit virtual address
space. Most distros AFAIK use 42-bit VA right now, but there are also
39-bit VA users too. The ppc64 handling can be used for this just fine
and support all the 3 sizes.
There are other issues, like allocator32 not really being able to support
the larger addres spaces, and hardcoded 39-bit address space size in other
macros.
Patch by Jakub Jelinek.
llvm-svn: 226639
glibc recently changed ABI on aarch64-linux:
https://sourceware.org/git/?p=glibc.git;a=commit;h=5c40c3bab2fddaca8cfe12d75944d1fef8adf1a4
Instead of having unsigned short mode; unsigned short __pad1; it now has
unsigned int mode; field in ipc_perm structure.
This patch allows to build against the recent glibc and disables the
ipc_perm.mode verification for older versions of glibc.
I think it shouldn't be a big deal even for older glibcs, I couldn't find
any place which would actually care about the exact mode field, rather than
the whole structure, appart from the CHECK_SIZE_AND_OFFSET macro.
Patch by Jakub Jelinek
llvm-svn: 226637
Use synci implementation of clear_cache for short address ranges.
For long address ranges, make a kernel call.
Differential Revision: http://reviews.llvm.org/D6661
llvm-svn: 226567
TSAN_SHADOW_COUNT is defined to 4 in all environments.
Other values of TSAN_SHADOW_COUNT were never tested and
were broken by recent changes to shadow mapping.
Remove it as there is no reason to fix nor maintain it.
llvm-svn: 226466
InternalAlloc is quite complex and its behavior may depend on the values of
flags. As such, it should not be used while parsing flags.
Sadly, LowLevelAlloc does not support deallocation of memory.
llvm-svn: 226453
Setting the maximum read size in FlagHandlerInclude to 2^15 might be a good
default, but causes the read to fail on systems with a page size larger than
that (ReadFileToBuffer(...) will fail if the maximum allowed size is less than
the value returned by GetPageSizeCached()). For example, on my PPC64/Linux
system, GetPageSizeCached() returns 2^16. In case the page size is larger, use
that instead.
llvm-svn: 226368
Debugging a missing profile is a bit painful right now. We can make
people's lives a bit easier by adding a knob to enable printing a
helpful error message for such failures.
llvm-svn: 226312
This test casts 0x4 to a function pointer and calls it. Unfortunately, the
faulting address may not exactly be 0x4 on PPC64 ELFv1 systems. The LLVM PPC
backend used to always generate the loads "in order", so we'd fault at 0x4
anyway. However, at upcoming change to loosen that ordering, and we'll pick a
different order on some targets. As a result, as explained in the comment, we
need to allow for certain nearby addresses as well.
llvm-svn: 226202
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
Use unwind.h to get the declarations for unwinding interfaces. This header is
already provided by clang and gcc, so this adds no additional dependencies for
building the builtins library. It avoids the duplication which may drift over
time though.
llvm-svn: 225990
pc_fd was not initialized to (-1) on some code paths, resulting in the program
erroneously closing stdin when reinitializing coverage.
llvm-svn: 225637
This mirrors r225239 to all the rest sanitizers:
ASan, DFSan, LSan, MSan, TSan, UBSan.
Now the runtime flag type, name, default value and
description is located in the single place in the
.inc file.
llvm-svn: 225327
Linux has 64k pages, so the old limit was only two pages. With ASLR the
initial sp might be right at the start of the second page, so the stack
will immediately grow down into the first page; and if you use all pages
of a limited stack then asan hits a kernel bug to do with how stack
guard pages are reported in /proc/self/maps:
http://lkml.iu.edu//hypermail/linux/kernel/1501.0/01025.html
We should still fix the underlying problems, but in the mean time this
patch makes the test work with 64k pages as well as it does with 4k
pages.
llvm-svn: 225261
Summary:
Introduce a single place where we specify flag type, name, default
value, and description. This removes a large amount of boilerplate
and ensures we won't leave flags uninitialized.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6851
llvm-svn: 225239
The clear_cache and enable_execute_stack tests attempt to memcpy the definition
of a function into a buffer before executing the function. The problem with
this approach is that on some targets (ARM with thumb mode compilation, MIPS
with MIPS16 codegen or uMIPS), you would use a pointer which is incorrect (it
would be off-by-one) due to the ISA selection being encoded into the address.
This ensures that the function address is retrieved correctly in all cases.
llvm-svn: 225215
Fix test failures by introducing CommonFlags::CopyFrom() to make sure
compiler doesn't insert memcpy() calls into runtime code.
Original commit message:
Protect CommonFlags singleton by adding const qualifier to
common_flags() accessor. The only ways to modify the flags are
SetCommonFlagsDefaults(), ParseCommonFlagsFromString() and
OverrideCommonFlags() functions, which are only supposed to be
called during initialization.
llvm-svn: 225088
We've got some internal users that either aren't compatible with this or
have found a bug with it. Either way, this is an isolated cleanup and so
I'm reverting it to un-block folks while we investigate. Alexey and
I will be working on fixing everything up so this can be re-committed
soon. Sorry for the noise and any inconvenience.
llvm-svn: 225079
This reverts commit r221445. This change leads to false positives
reports from -fsanitize=vptr. See original commit thread for more
details.
llvm-svn: 224972
Summary:
Its seems to be replaced by clang_darwin.mk in the Makefile-based
build, and is only referenced in unittest scripts, which are
broken for a long time now.
Test Plan: n/a
Reviewers: bob.wilson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6574
llvm-svn: 224946
LLVM_LIBDIR_SUFFIX variable to one place in the cmake file.
This is all that I had to do to get everything from compiler-rt working
for me, but there may be more work required if folks are relying on more
parts of compiler-rt. Notably, I'm mostly using it for the sanitizers.
llvm-svn: 224928
The change in r224819 started using internal_unlink in a sanitizer_common unit test. For some reason, internal_unlink is not defined in sanitizer_mac.cc, fixing that.
llvm-svn: 224910
This increases the limit from 4M locations to 16M, reserving
64Mb virtual memory. Chrome has >5M unique coverage locations with coverage=3.
llvm-svn: 224855
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
The current code leaves the first event in the trace part uninitialized
(from the previous thread). It can cause unpredictable behavior
during stack/mutexset restoration.
Initialize the first event to a fake harmless memory access.
llvm-svn: 224834
This is mostly useful for testing, as the only other way of specifying
activation options (Android system property) is system-wide and affects
concurrently running tests.
llvm-svn: 224824
Summary:
This test failed because clang compiled the call to memset() into a
single sth instruction, instead of a call. Fix it by using write() instead
of memset().
Reviewers: kcc, samsonov, garious, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6776
llvm-svn: 224812
The compiler-rt CMake build currently uses -gline-tables-only for all builds. While this makes the debugger correctly map source files, debugging of the runtime libraries in general is pretty tough, because you don't see any local variables, parameters, etc. Let's allow emitting full debugging info by setting COMPILER_RT_DEBUG=ON.
Reviewed at http://reviews.llvm.org/D6764
llvm-svn: 224749
Summary:
Protect CommonFlags singleton by adding const qualifier to
common_flags() accessor. The only ways to modify the flags are
SetCommonFlagsDefaults(), ParseCommonFlagsFromString() and
OverrideCommonFlags() functions, which are only supposed to be
called during initialization.
Test Plan: regression test suite
Reviewers: kcc, eugenis, glider
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6741
llvm-svn: 224736
As mentioned in
https://code.google.com/p/address-sanitizer/issues/detail?id=365, when the
re-exec that adds the required DYLD_INSERT_LIBRARIES variable fails, ASan
currently continues to run, but things are broken (some memory can be
overwritten, interceptors don't work, ...). This patch aborts if the execv()
fails and prints an error message that DYLD_INSERT_LIBRARIES is required. It
also removes the "alllow_reexec" flag, since using it causes the same issues.
Reviewed at http://reviews.llvm.org/D6752
llvm-svn: 224712
NULL handler
Per
https://developer.apple.com/library/mac/documentation/Performance/Reference/GCD_libdispatch_Ref/index.html,
the dispatch_source_set_cancel_handler() API *can* be called with a NULL
handler. In that case, the libdispatch removes an already existing cancellation
handler, if there was one. ASan's interceptor always creates a new block that
always tries to call the original handler. In case the original block is NULL,
a segmentation fault happens. Let's fix that by not wrapping a NULL-block at
all.
It looks like all the other libdispatch APIs (which we intercept) do *not*
allow NULL. So it's really only the dispatch_source_set_cancel_handler one that
needs this fix.
Reviewed at http://reviews.llvm.org/D6747
llvm-svn: 224711
The ASan test/asan/TestCases/log-path_test.cc testcase uses /INVALID as an invalid path and expects that the program will not be allowed to create or write to that file. This actually is a valid writable path on one of my setups. Let's make the path more invalid.
Reviewed at http://reviews.llvm.org/D6727
llvm-svn: 224694
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
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
Summary:
Change the way ASan flag parsing is performed at activation: instead
of overwriting all ASan and common flags from the activation string,
ASan will now only override a handful of whitelisted flags.
This is a first step towards making runtime flags immutable after
initialization. I plan to re-factor the activation stragegy to
the following one:
- Parse commandline flags. Override the defaults from compile
definition, env var, etc. Flags are immutable at this point.
- Initiailize the runtime from commandline flags.
- If ASan needs to be started deactivated, stash the runtime
state in "asan_deactivated_flags" and deactivate the runtime.
- When ASan is activated, override "asan_deactivated_flags" with
activation flags, and use it to re-activate the runtime.
Test Plan: regression test suite
Reviewers: eugenis, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6709
llvm-svn: 224601
clang does not like the definition of builtins. In order to work around this,
we use a SUN CC to redefine the generated name. However, this requires that we
account for the user label prefix. Rather than hard coding that into the file,
rely on the compiler to tell us the information and use the preprocessor to
generate the name as we do in the assembly routines. NFC.
llvm-svn: 224597
The test got silently disabled because of a typo in the lit config.
Also, compiler flags have changed (asan-coverage -> fsanitize-coverage).
llvm-svn: 224569
signal handler reads sa_sigaction when a concurrent sigaction call can modify it
as the result in could try to call SIG_DFL or a partially overwritten function pointer
llvm-svn: 224530
Summary:
Always quote suppressions files given to *_OPTIONS.
This will make it not break when given full Windows paths (otherwise,
parsing would stop after the drive's letter + ':').
Also fix one or two cases where the suppression files' extensions were
not *.supp.
Reviewers: samsonov, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6680
llvm-svn: 224529
Summary:
The numbers in /proc/self/statm are in pages, not in fixed 4k units.
This fixes Linux/hard_rss_limit_mb_test.cc on my PowerPC64 box which
has 64k pages.
Reviewers: kcc, willschm
Reviewed By: willschm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6717
llvm-svn: 224522
currently it fails in cmake build with weird errors:
/tmp/real_deadlock_detector_stress_test-68a5ae.o: In function `__clang_call_terminate':
/ssd/src/llvm/projects/compiler-rt/test/tsan/real_deadlock_detector_stress_test.cc:(.text.__clang_call_terminate[__clang_call_terminate]+0x12): undefined reference to `__cxa_begin_catch'
/ssd/src/llvm/projects/compiler-rt/test/tsan/real_deadlock_detector_stress_test.cc:(.text.__clang_call_terminate[__clang_call_terminate]+0x17): undefined reference to `std::terminate()'
/tmp/real_deadlock_detector_stress_test-68a5ae.o: In function `std::vector<int, std::allocator<int> >::_M_check_len(unsigned long, char const*) const':
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:1339: undefined reference to `std::__throw_length_error(char const*)'
/tmp/real_deadlock_detector_stress_test-68a5ae.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
/tmp/real_deadlock_detector_stress_test-68a5ae.o:(.eh_frame+0x63): undefined reference to `__gxx_personality_v0'
clang-3.5: error: linker command failed with exit code 1 (use -v to see invocation)
llvm-svn: 224511
tctx==NULL crash observed during deadlock reporting.
There seems to be some bugs in the deadlock detector,
but it is still useful to be more robust during reporting.
llvm-svn: 224508
-fsized-delete is implemented via weak symbols, and doesn't work
properly when malloc/free replacements are provided in shared
ASan runtime.
llvm-svn: 224474
This commit changes the strategy for building shared ASan runtime
and the way we test it:
- COMPILER_RT_BUILD_SHARED_ASAN CMake option is removed. We now
always build shared ASan runtime (it is the default on Android,
Windows and Mac, and not the default on Linux and FreeBSD).
- Platforms, which use static runtime by default now have
"check-asan-dynamic" testsuite. This testsuite contains instrumented
unit tests, and ASan lit tests, and runs them with shared ASan
runtime. This testsuite is *not* a part of "check-asan" and
*not* a part of "check-all", as adding 1000 more test cases, which
duplicate existing ones is costly. However, you're welcome to
add this command to your buildbot.
llvm-svn: 224470
pthread_getspecific is not async-signal-safe.
MsanThread pointer is now stored in a TLS variable, and the TSD slot
is used only for its destructor, and never from a signal handler.
This should fix intermittent CHECK failures in MsanTSDSet.
llvm-svn: 224423
Introduce "Allocator" object, which contains all the bits and pieces
ASan allocation machinery actually use: allocator from sanitizer_common,
quarantine, fallback allocator and quarantine caches, fallback mutex.
This step is a preparation to adding more state to this object. We want
to reduce dependency of Allocator on commandline flags and be able to
"safely" modify its behavior (such as the size of the redzone) at
runtime.
llvm-svn: 224406
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
We recently had a broken version check because an newer OS X version is treated as MACOS_VERSION_UNKNOWN which is less than all the defined values. Let's have a separate enum value for unknown but newer versions, so the ">=" and "<=" version checks still work even in upcoming OS X releases.
Reviewed at http://reviews.llvm.org/D6137
llvm-svn: 224315
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
On mips64 addresses are 40-bit. Where as a 48 bit address is used in TypeCheck/misaligned.cpp.
Using regular expression for that address.
reviewed by : samsonov
submitted by: sagar
llvm-svn: 224242
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
This commit changes the way we get fake stack from ASan runtime
(to find use-after-return errors) and the way we represent local
variables:
- __asan_stack_malloc function now returns pointer to newly allocated
fake stack frame, or NULL if frame cannot be allocated. It doesn't
take pointer to real stack as an input argument, it is calculated
inside the runtime.
- __asan_stack_free function doesn't take pointer to real stack as
an input argument. Now this function is never called if fake stack
frame wasn't allocated.
- __asan_init version is bumped to reflect changes in the ABI.
- new flag "-asan-stack-dynamic-alloca" allows to store all the
function local variables in a dynamic alloca, instead of the static
one. It reduces the stack space usage in use-after-return mode
(dynamic alloca will not be called if the local variables are stored
in a fake stack), and improves the debug info quality for local
variables (they will not be described relatively to %rbp/%rsp, which
are assumed to be clobbered by function calls). This flag is turned
off by default for now, but I plan to turn it on after more
testing.
llvm-svn: 224063
Summary:
- Make sure mmap() is never called inside RawWrite function.
- Wrap a bunch of standalone globals in a ReportFile object.
- Make sure accesses to these globals are thread-safe.
- Fix report_path functionality on Windows, where
__sanitizer_set_report_path() would break program.
I've started this yak shaving in order to make
"CommonFlags::mmap_limit_mb" immutable. Currently we drop this flag
to zero before printing an error message.
Test Plan: regression test suite
Reviewers: kcc, glider
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6595
llvm-svn: 224031
Each of the object formats use a different directive for selecting the constant
section. Use a macro to avoid the duplication across a number of files. Also
correct a small macro mismatch on the Windows case (HIDDEN_DIRECTIVE -> HIDDEN).
Patch by Vadim Chugunov!
llvm-svn: 223910
On Darwin, compiler_rt uses magic linker symbols to find the profile
counters in the __DATA segment. This is a reasonable method for
normal, hosted, userspace programs. However programs with custom
memory layouts, such as the kernel, will need to tell compiler_rt
explicitly where to find these sections.
Patch by Lawrence D'Anna. Thanks!
llvm-svn: 223840
This was causing build failures on llvm-clang-lld-x86_64-centos-6.5 for some
reason. Anyway, the new way is better because we no longer rely on std::thread
implementation details.
llvm-svn: 223480
this test is flaky because of ASLR
app memory is 7e8000000000-800000000000,
there may or may not be a 1TB hole depending on
where ASLR will choose to map libraries
llvm-svn: 223469
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
When CMake builds a dynamic library on Windows, the .dll file's location is
determined by the RUNTIME_OUTPUT_DIRECTORY, which we were previously not
setting.
This means for example that clang_rt.asan_dynamic-i386.dll will get built
and installed in the same directory as the corresponding .lib file,
instead of being built in the bin/ directory and not installed at all.
Differential Revision: http://reviews.llvm.org/D6508
llvm-svn: 223387
Previously, all origin ids were "chained" origins, i.e values of
ChainedOriginDepot. This added a level of indirection for simple
stack and heap allocation, which were represented as chains of
length 1. This costs both RAM and CPU, but provides a joined 2**29
origin id space. It also made function (any instrumented function)
entry non-async-signal-safe, but that does not really matter because
memory stores in track-origins=2 mode are not async-signal-safe anyway.
With this change, the type of the origin is encoded in origin id.
See comment in msan_origin.h for more details. This reduces chained and stack
origin id range to 2**28 each, but leaves extra 2**31 for heap origins.
This change should not have any user-visible effects.
llvm-svn: 223233
Return a linked list of AddressInfo objects, instead of using an array of
these objects as an output parameter. This simplifies the code in callers
of this function (especially TSan).
Fix a few memory leaks from internal allocator, when the returned
AddressInfo objects were not properly cleared.
llvm-svn: 223145
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
MSan does not assign origin for instrumentation temps (i.e. the ones that do
not come from the application code), but "select" instrumentation erroneously
tried to use one of those.
https://code.google.com/p/memory-sanitizer/issues/detail?id=78
llvm-svn: 222918
They don't test what they claim to because LD_PRELOAD applies to "not" instead
of the actual test binary. And all Android tests run with LD_PRELOAD anyway.
llvm-svn: 222835
Summary:
First, remove lit configuration that sets ASAN_OPTIONS to detect_leaks=1
because this is already the default when leak detection is supported.
This removes a bit of duplication between various lit.cfg files.
Second, add a new feature 'leak-detection' if we're targetting x86_64
(not i386) on Linux.
Third, change a couple of tests that need leak detection to require the
new 'leak-detection' feature.
Reviewers: kcc, earthdok, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6396
llvm-svn: 222738
Summary:
Exactly what the title says. I've tested this change against the libc++ test failures and it solves all of them. The check-msan rule also still passes.
I'm not sure why it called memset originally.
I can add tests if requested but currently there are no tests involving wide chars and they are a c++11 features.
Reviewers: kcc, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6352
llvm-svn: 222673
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:
This test explicitly sets ASAN_OPTIONS=detect_leaks=1 which is only
supported on x86-64. The test is currently restricted to run only on
64-bit targets, but needs to be restricted further so it only runs on
x86-64.
Reviewers: kcc, eugenis, earthdok, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6189
llvm-svn: 222091