According to man freopen, passing NULL instead of a filename is valid, however the current implementation of the interceptor assumes this parameter is non-NULL. Let's fix that and add a test case.
Differential Revision: http://reviews.llvm.org/D11389
llvm-svn: 242787
Since http://reviews.llvm.org/D10294, ASan test cases now respect default env. options via `ASAN_OPTION=$ASAN_OPTIONS:additional_options=xxx`. This patch adds this to a few test cases where it's still missing.
Differential Revision: http://reviews.llvm.org/D10988
llvm-svn: 241571
On OS X 10.11 (which is currently a public beta), the dynamic linker has been improved so that it doesn't require the use of DYLD_INSERT_LIBRARIES in order for interposition/wrappers to work. This patch adds support of this behavior into ASan – we no longer need to re-exec in case the env. variable is not set.
Reviewed at http://reviews.llvm.org/D10924
llvm-svn: 241487
On OS X, when the main instrumented binary contains a custom section with zero length, ASan will crash (assert failure) early in the initialization.
Reviewed at http://reviews.llvm.org/D10944
llvm-svn: 241474
The test simulates a sandbox that prevents the program from calling readlink().
ASan is supposed to still be able to print the executable name regardless of that.
llvm-svn: 241072
We were unsetting DYLD_ROOT_PATH before calling atos on Darwin in order to
address it not working for symbolicating 32 bit binaries. (atos essentiall
tries to respawn as a 32 bit binary and it's disallowed to respawn if
DYLD_ROOT_PATH is set ... ) However, processes rely on having DYLD_ROOT_PATH
set under certain conditions, so this is not the right fix. In particular, this
always crashes when running ASanified process under the debugger in Xcode with
iOS simulator, which is a very important workflow for us to support.
This patch reverts the unsetting of the DYLD_ROOT_PATH. The correct fix to the
misbehavior on 32-bit binaries should happen inside atos.
http://reviews.llvm.org/D10722
llvm-svn: 240724
Summary:
This commit adds symbolize_vs_style=false to every instance of
ASAN_OPTIONS in the asan tests and sets
ASAN_OPTIONS=symbolize_vs_style=false in lit, for tests which don't set
it.
This way we don't need to make the tests be able to deal with both
symbolize styles.
This is the first patch in the series. I will eventually submit for the
other sanitizers too.
We need this change (or another way to deal with the different outputs) in
order to be able to default to symbolize_vs_style=true on some platforms.
Adding to this change, I'm also adding "env " before any command line
which sets environment variables. That way the test works on other host
shells, like we have if the host is running Windows.
Reviewers: samsonov, kcc, rnk
Subscribers: tberghammer, llvm-commits
Differential Revision: http://reviews.llvm.org/D10294
llvm-svn: 239754
Without the --target flag, clang uses the mips64 triple which selects the n64 abi. We need to add --target=mips-linux-gnu, so that clang can select the correct abi for mips32r2.
Reviewers: dsanders, kcc, samsonov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential Revision: http://reviews.llvm.org/D9249
llvm-svn: 237675
Current code tries to find the dynamic TLS header to the left of the
TLS block without checking that it's not a static TLS allocation.
llvm-svn: 237495
This test was failing on mips because mips addresses are 40-bit long.
Using regex for address solves this issue.
Reviewers: dsanders, kcc, samsonov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential Revision: http://reviews.llvm.org/D9516
llvm-svn: 236844
Summary:
During the review of http://reviews.llvm.org/D9199 where I had originally
changed the debug_mapping.cc test to accept hexadecimal values, we realized
that SHADOW_SCALE and SHADOW_GRANULARITY ought to be printed as decimal values.
This patch makes that change.
This patch also adds a '0x' prefix to the SHADOW_OFFSET to make it clear that
it is hexadecimal while the other two are decimal.
Reviewers: kcc, timurrrr, samsonov
Reviewed By: timurrrr, samsonov
Subscribers: samsonov, llvm-commits, sagar
Differential Revision: http://reviews.llvm.org/D9224
llvm-svn: 235798
Summary:
Previously the CHECK directive for SHADOW_SCALE only matched decimal digits
causing it to match '7' on x86_64 instead of the whole value.
This fixes a failure on mips-linux-gnu targets where the leading digit is 'a'.
Reviewers: kcc, sagar, timurrrr
Reviewed By: timurrrr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9199
llvm-svn: 235594
This patch is related to Issue 346: moar string interceptors: strstr, strcasestr, strcspn, strpbrk
As was suggested in original review http://reviews.llvm.org/D6056 a new "strict_string_checks" run-time flag introduced.
The flag support applied for existing common, asan, msan and tsan interceptors. New asan tests added.
Change by Maria Guseva reviewed in http://reviews.llvm.org/D7123
llvm-svn: 234187
This CL:
- moves PrepareForSandboxing() to sanitizer_posix_libcdep.cc
- fixes the coverage tests to use flag substitutions defined in r233802 and not rely on hardcoded shared library names
- moves those tests to TestCases/Posix so that they can be executed on Darwin
llvm-svn: 233828
r233802 has moved the tests above to Posix/ and introduced %ld_flags_rpath_so and %ld_flags_rpath_exe,
which haven't been defined for FreeBSD.
We expect the flags to be the same on Linux and FreeBSD. If there's another reason for the tests to fail on FreeBSD,
they'll need to be disabled.
llvm-svn: 233822
Also make suppressions-library.cc use the same flags to avoid warnings about unused -rpath flags.
The same substitutions will be used to make coverage tests work on both Linux and Darwin without duplicating the code.
llvm-svn: 233802
On OS X, dladdr() provides mangled names only, so we need need to demangle in
DlAddrSymbolizer::SymbolizePC.
Reviewed at http://reviews.llvm.org/D8291
llvm-svn: 232910
This patch changes the symbolizer chain on OS X (which currently only uses 1
symbolizer at most) to use this behavior:
* By default, use LLVMSymbolizer -> DlAddrSymbolizer.
* If the llvm-symbolizer binary is not found, use AtosSymbolizer
-> DlAddrSymbolizer.
* If the user specifies ASAN_SYMBOLIZER_PATH=.../atos, then use AtosSymbolizer
-> DlAddrSymbolizer.
* If neither llvm-symbolizer or atos is found, or external symbolication is
disabled with ASAN_SYMBOLIZER_PATH="", use DlAddrSymbolizer.
Reviewed at http://reviews.llvm.org/D8285
llvm-svn: 232908
This test started passing without warning, so in theory, we shouldn't mark
is as XPASS, but the buildbots are red and there's been an uncaught regression
meanwhile. Since it's passing on {ARM,Thumb2} x {NEON,VFPv3}, I'll risk future
failures for the benefit of getting the bots green again.
llvm-svn: 232642
Make sure SUMMARY is always reported unless print_summary flag is set to
false, even if symbolizer is unavailable or report stack trace is empty.
If file/line info for PC can't be evaluated, print module name/offset
like we do in stack trace.
llvm-svn: 232567
The experiments can be used to evaluate potential optimizations that remove
instrumentation (assess false negatives). Instead of completely removing
some instrumentation, you set Exp to a non-zero value (mask of optimization
experiments that want to remove instrumentation of this instruction).
If Exp is non-zero, this pass will emit special calls into runtime
(e.g. __asan_report_exp_load1 instead of __asan_report_load1). These calls
make runtime terminate the program in a special way (with a different
exit status). Then you run the new compiler on a buggy corpus, collect
the special terminations (ideally, you don't see them at all -- no false
negatives) and make the decision on the optimization.
The exact reaction to experiments in runtime is not implemented in this patch.
It will be defined and implemented in a subsequent patch.
http://reviews.llvm.org/D8198
llvm-svn: 232501
1. /proc/self/smaps may be bigger than 1 << 14. On my machine, it is
26KB.
2. The read system call may return a partially filled buffer. We need
to check the return value from read.
Patch by H.J. Lu
llvm-svn: 231502
Long story short: stop-the-world briefly resets SIGSEGV handler to SIG_DFL.
This breaks programs that handle and continue after SIGSEGV (namely JVM).
See the test and comments for details.
This is reincarnation of reverted r229678 (http://reviews.llvm.org/D7722).
Changed:
- execute TracerThreadDieCallback only on tracer thread
- reset global data in TracerThreadSignalHandler/TracerThreadDieCallback
- handle EINTR from waitpid
Add 3 new test:
- SIGSEGV during leak checking
- StopTheWorld operation during signal storm from an external process
- StopTheWorld operation when the program generates and handles SIGSEGVs
http://reviews.llvm.org/D8032
llvm-svn: 231367
It broke down at some point, and all tests with
REQUIRES: asan-(32|64)-bits
line stopped being executed. Restore the intended behavior.
llvm-svn: 231325
The ASanified executable could be launched from different locations. When we
cannot find the suppression file relative to the current directory, try to
see if the specified path is relative to the location of the executable.
llvm-svn: 230723
Sorry, SVN had some weird problems so I had to revert and reapply the patch
locally a couple of times and didn't notice I've added file contents to the same
file....
llvm-svn: 230505
When AddressSanitizer only a single dynamic alloca and no static allocas, due to an early exit from FunctionStackPoisoner::poisonStack we forget to unpoison the dynamic alloca. This patch fixes that.
Reviewed at http://reviews.llvm.org/D7810
llvm-svn: 230317
Revise the fix to https://code.google.com/p/address-sanitizer/issues/detail?id=178:
always disable strict init-order checking the first time dlopen() is
called: at this point shared library is allowed to access globals
defined in the main executable, as they are guaranteed to be
initialized. Revise the test cases:
* simplify init-order-dlopen.cc test case: make it Linux-specific
(there's no strict init-order checking on other platforms anyway),
and single-threaded.
* reinforce init-order-pthread-create.cc test case: make sure that
init-order checker would produce a false positive unless we
turn it off at the moment we call pthread_create().
llvm-svn: 230288
This reverts commit r230019, as it was breaking the ARM sanitizer buildbot
and let other errors be introduced since it wasn't fixed/reverted in
time.
llvm-svn: 230179
The gc-test.cc tries underflows of a variable up to -32 bytes, but on i386, the left redzone is not 32 bytes, it’s only 16 bytes and therefore the access to var[-32] is completely off. The reason why this test didn’t fail before is that we’ve been lucky and there was another variable before the var array, which was also instrumented. This fix uses “-32” for 64-bit systems and “-16” for 32-bit.
Reviewed at http://reviews.llvm.org/D7809
llvm-svn: 230172
Summary:
It still gets picked up by ASan, but it also gets picked up by the other
test suites.
Otherwise, some test suites (e.g: UBSan) would complain they had no
dependencies, and wouldn't run.
Reviewers: samsonov, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7740
llvm-svn: 229962
The internal shell is faster and more predictable than any copy of
bash.exe on the user's system.
LLVM and Clang use the internal shell by default, and have an
environment variable to disable it. I don't think compiler-rt needs that
complexity, so I left it out.
llvm-svn: 229560
MaybeReexec() in asan_mac.cc checks for presence of the ASan dylib in DYLD_INSERT_LIBRARIES, and if it is there, it will process this env. var. and remove the dylib from its value, so that spawned children don't have this variable set. However, the current implementation only works when using a canonical absolute path to the dylib, it fails to remove the dylib for example when using @executable_path.
This patch changes the processing of DYLD_INSERT_LIBRARIES to comparing values only based on filenames (ignoring directories).
Reviewed at http://reviews.llvm.org/D7160
llvm-svn: 228392
by manually adding __asan_mz_* to the generated interface functions list.
Declaring these functions in asan_interface_internal.h doesn't work quite well:
their prototypes must match the prototypes of zone functions in malloc/malloc.h,
but some of the types (e.g. malloc_zone_t and size_t) aren't available in
asan_interface_internal.h
llvm-svn: 228290
Modifying Darwin/interception-in-shared-lib-test.cc and suppressions-library.cc
to use rpath instead of linking against the full path to the temporary file.
NFC.
llvm-svn: 227161
The idea is to ensure that the ASan runtime gets initialized early (i.e.
before other initializers/constructors) even when DYLD_INSERT_LIBRARIES
is not used. In that case, the interceptors are not installed (on OS X,
DYLD_INSERT_LIBRARIES is required for interceptors to work), and therefore
ASan gets currently initialized quite late -- from the main executable's
module initializer. The following issues are a consequence of this:
https://code.google.com/p/address-sanitizer/issues/detail?id=363https://code.google.com/p/address-sanitizer/issues/detail?id=357
Both of them are fixed with this patch.
Reviewed at http://reviews.llvm.org/D7117
llvm-svn: 226929
This patch is a proposed solution for https://code.google.com/p/address-sanitizer/issues/detail?id=375:
When the stacktraces are captured and printed by ASan itself, they are fine, but when the program has already printed the report (or is just printing it), capturing a stacktrace via other means is broken. "Other means" include OS X CrashReporter, debuggers or calling backtrace() within the program. For example calling backtrace() from a sanitizer_set_death_callback function prints a very truncated stacktrace.
Reviewed at http://reviews.llvm.org/D7103
llvm-svn: 226878
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
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
Kuba Brecka