In more recent Linux kernels with 47 bit VMAs the layout of virtual memory
for powerpc64 changed causing the address sanitizer to not work properly. This
patch fixes up a test case that was found to fail on some newer Fedora
releases that use different address ranges.
ref: https://reviews.llvm.org/D40907
llvm-svn: 323217
Summary:
One test-case uses a wrong operation (should be subtraction).
Second test-case should declare a global variables before a tested one
in order to guarantee we will find a red-zone.
Reviewers: kcc, jakubjelinek, alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D41481
llvm-svn: 323162
sequentially.
The current implementation of commands in
`test/sanitizer_common/ios_commands/` for iOS devices cannot be executed
in parallel which results in the ASan and TSan tests failing when
executed in parallel by lit which was the default behaviour.
We now force the ASan and TSan tests to be a new parallelism group named
`darwin-ios-device-sanitizer` which allows only one test to be run at a
time. We also emit a warning informing the user that tests are being
run sequentially.
This only applies if the target is an iOS device.
Differential Revision: https://reviews.llvm.org/D42156
llvm-svn: 323026
Summary:
This patch (on top of the previous two (https://reviews.llvm.org/D40898 and
https://reviews.llvm.org/D40899) complete the compiler-rt side of the the Solaris
sanitizer port.
It contains the following sets of changes:
* For the time being, the port is for 32-bit x86 only, so reject the various tests on
x86_64.
* When compiling as C++, <setjmp.h> resp. <iso/setjmp_iso.h> only declares
_setjmp and _longjmp inside namespace std.
* MAP_FILE is a Windows feature. While e.g. Linux <sys/mman.h> provides a
no-op compat define, Solaris does not.
* test/asan/TestCases/Posix/coverage.cc was initially failing like this:
/vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py: 4 files merged; 2 PCs total
rm: cannot remove '/var/gcc/llvm/local/projects/compiler-rt/test/asan/I386SunOSConfig/TestCases/Posix/Output/coverage': Invalid argument
Further digging revealed that the rm was trying to remove the running test's working
directory which failed as observed. cd'ing out of the dir before let the test pass.
* Two tests needed a declaration of alloca. I've now copied the existing code from
test/asan/TestCases/alloca_constant_size.cc, but it may be more profitable and
maintainable to have a common testsuite header where such code is collected.
* Similarly, Solaris' printf %p format doesn't include the leading 0x.
* In test/asan/TestCases/malloc-no-intercept.c, I had to undef __EXTENSIONS__
(predefined by clang for no apparent reason) to avoid conflicting declarations
for memalign.
* test/ubsan/TestCases/Float/cast-overflow.cpp has different platform dependent
ways to define BYTE_ORDER and friends. Why not just use __BYTE_ORDER__ and
friends as predefined by clang and gcc?
Patch by Rainer Orth.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, krytarowski, fedor.sergeev, JDevlieghere, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40900
llvm-svn: 322635
Summary:
Export aligned new/delete to make dynamic runtimes work again.
Remove all valid new/delete cases from ASan test, there's a test in
common for that.
Reviewers: eugenis
Subscribers: srhines, kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41548
llvm-svn: 321394
There could be a situation when a specific DSO was built with FORTIFY_SOURCE option. In case asan-ed binary link against that DSO,
libasan can't handle the possible memory error because it does not have interceptors for spinrtf_chk, snprintf_chk, vprintf_chk,
vsnprintf_chk, __fprintf_chk functions. Let's interceptors for them.
Patch by Denis Khalikov.
Differential Revision: https://reviews.llvm.org/D40951
llvm-svn: 320990
In more recent Linux kernels with 47 bit VMAs the layout of virtual memory
for powerpc64 changed causing the address sanitizer to not work properly. This
patch adds support for 47 bit VMA kernels for powerpc64 and fixes up test
cases.
https://reviews.llvm.org/D40908
There is an associated patch for trunk.
Tested on several 4.x and 3.x kernel releases.
llvm-svn: 320110
Following patch adds support of all memory origins in
CheckForInvalidPointerPair function. For small difference of pointers,
it's directly done in shadow memory (the limit was set to 2048B).
Then we search for origin of first pointer and verify that the second
one has the same origin. If so, we verify that it points either to a same
variable (in case of stack memory or a global variable), or to a same
heap segment.
Committing on behanf of marxin and jakubjelinek.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits
Differential revision: https://reviews.llvm.org/D40600
llvm-svn: 319668
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319575
This reverts commit r319525.
This change has introduced a problem with the Lit tests build for compiler-rt using Gold: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/6047/steps/test%20standalone%20compiler-rt/logs/stdio
llvm-lit: /b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg', traceback: Traceback (most recent call last):
File "/b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 37, in <module>
if root.host_os not in ['Linux'] or not is_gold_linker_available():
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 27, in is_gold_linker_available
stderr = subprocess.PIPE)
File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
llvm-svn: 319529
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319525
On macOS, we usually don't require launching the target with DYLD_INSERT_LIBRARIES anymore. However, it is still necessary when running a target that is not instrumented (and e.g. dlopen's an instrument library later). In any case, ASan and TSan currently remove themselves from the DYLD_INSERT_LIBRARIES environment variable to avoid passing it onto children. This works well e.g. when instrumenting a shell. A problem arises when the target is a non-instrumented shim (e.g. "xcrun") that either re-execs or launches a child that is supposed to get DYLD_INSERT_LIBRARIES propagated. To support this mode, this patch introduces 'strip_env' flag that can be used to keep DYLD_INSERT_LIBRARIES untouched.
Differential Revision: https://reviews.llvm.org/D39991
llvm-svn: 319365
It's explicitly forbidden to call fclose with NULL, but at least on Darwin, this succeeds and doesn't segfault. To maintain binary compatibility, ASan should survice fclose(NULL) as well.
Differential Revision: https://reviews.llvm.org/D40053
llvm-svn: 319347
Calling getpwnam(NULL) is probably a bug, but at least on Darwin, such a call succeeds without segfaulting. I have some existing code that relies on that. To maintain binary compatibility, ASan should also survive a call to getpwnam with NULL.
Differential Revision: https://reviews.llvm.org/D40052
llvm-svn: 319344
PDB emission now works well enough that we can rely on it for these
tests to pass.
Differential Revision: https://reviews.llvm.org/D40188
llvm-svn: 318546
The tests are ported as follows:
contiguous_container_crash.cc
use-after-delete.cc
use-after-free.cc
Replace hardwired shadow granularity in CHECK statements with regex.
max_redzone.cc
Bump max_redzone parameter to 32.
memset_test.cc
Bump size parameter of __asan_poison_memory_region to 32.
scariness_score_test.cc
For "far-from-bounds" heap overflow, make sure overflow is more than
one shadow granularity away.
At large shadow granularity, there is not enough redzone between
stack elements to detect far-from-bounds, so fake out that test.
Differential Revision: https://reviews.llvm.org/D39773
llvm-svn: 318470
ASan allocator stores the requested alignment for new and new[] calls
and on delete and delete[] verifies that alignments do match.
The representable alignments are: default alignment, 8, 16, 32, 64, 128,
256 and 512 bytes. Alignments > 512 are stored as 512, hence two
different alignments > 512 will pass the check (possibly masking the bug),
but limited memory requirements deemed to be a resonable tradeoff for
relaxed conditions.
The feature is controlled by new_delete_type_mismatch flag, the same one
protecting new/delete matching size check.
Differential revision: https://reviews.llvm.org/D38574
Issue: https://github.com/google/sanitizers/issues/799
llvm-svn: 316595
Summary:
Purging allocator quarantine and returning memory to OS might be desired
between fuzzer iterations since, most likely, the quarantine is not
going to catch bugs in the code under fuzz, but reducing RSS might
significantly prolong the fuzzing session.
Reviewers: cryptoad
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D39153
llvm-svn: 316347
This is a very poorly named feature. I think originally it meant to cover linux only, but the use of it in msan
seems to be about any aarch64 platform. Anyway, this change should be NFC on everything except Android.
llvm-svn: 315389
compunit's .data section. This vector is not poisoned. Because of this the
first symbol of the following section has no left red zone. As a result, ASan
cannot detect underflow for such symbols.
Poison ASan allocated metadata, it should not be accessible to user code.
This fix does not eliminate the problem with missing left red zones but it
reduces the set of vulnerable symbols from first symbols in each input data
section to first symbols in the output section of the binary.
Differential Revision: https://reviews.llvm.org/D38056
llvm-svn: 314365
Linux for mips has a non-standard layout for the kernel sigaction struct.
Adjust the layout by the minimally amount to get the test to pass, as we
don't require the usage of the restorer function.
llvm-svn: 314200
Don't overwrite exit code in LSan when running on top of ASan in recovery mode
to avoid breakage of users code due to found leaks.
Patch by Slava Barinov.
Differential Revision: https://reviews.llvm.org/D38026
llvm-svn: 313966
Summary:
1. Update ubsan_interface.inc to make the test happy.
2. Switch interface_symbols_linux and interface_symbols_darwin to C++ to import __ubsan_handle_dynamic_type_cache_miss
3. Switch interface_symbols_windows to C++ for consistency.
Reviewers: rnk, zturner
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D37986
llvm-svn: 313551
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311924
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311842
Summary:
`pvalloc` appears to not be available on Android. Mark the failing test as
unsupported on that platform.
Reviewers: alekseyshl, vitalybuka
Reviewed By: alekseyshl, vitalybuka
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D36339
llvm-svn: 310133
Summary:
Last one of the `pvalloc` overflow checks!
`CheckForPvallocOverflow` was introduced with D35818 to detect when `pvalloc`
would wrap when rounding up to the next multiple of the page size.
Add this check to ASan's `pvalloc` implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D36257
llvm-svn: 310119
Summary:
Included is one test for passing structs by value and one test for
passing C++
objects by value.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34827
llvm-svn: 309424
atos is the default symbolizer on Apple's compiler for quite a few years now.
llvm-symbolizer is quite fragile on Darwin: for example, unless a .dSYM
file was explicitly generated symbolication would not work.
It is also very convenient when the behavior of LLVM open source
compiler matches to that of Apple's compiler on Apple's platform.
Furthermore, llvm-symbolizer is not installed on Apple's platform by
default, which leads to strange behavior during debugging: the test
might fail under lit (where it has llvm-symbolizer) but would run
properly when launched on the command line (where it does not, and atos
would be used).
Indeed, there's a downside: atos does not work properly with inlined
functions, hence the test change.
We do not think that this is a major problem, as users would often
compile with -O0 when debugging, and in any case it is preferable to
symbolizer not being able to symbolize.
Differential Revision: https://reviews.llvm.org/D35745
llvm-svn: 308908
Summary:
Set proper errno code on alloction failures and change some
implementations to satisfy their man-specified requirements:
LSan: valloc and memalign
ASan: pvalloc, memalign and posix_memalign
Changing both allocators in one patch since LSan depends on ASan allocator in some configurations.
Reviewers: vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D35440
llvm-svn: 308064
Revert "Copy arguments passed by value into explicit allocas for ASan."
Revert "[asan] Add end-to-end tests for overflows of byval arguments."
Build failure on lldb-x86_64-ubuntu-14.04-buildserver.
Test failure on clang-cmake-aarch64-42vma and sanitizer-x86_64-linux-android.
llvm-svn: 307345
Included is one test for passing structs by value and one test for passing C++
objects by value.
Patch by Matt Morehouse.
Differential revision: https://reviews.llvm.org/D34827
llvm-svn: 307343
This fixes an issue with the emission of lifetime markers for struct-returning Obj-C msgSend calls. When the result of a struct-returning call is ignored, the temporary storage is only marked with lifetime markers in one of the two branches of the nil-receiver-check. The check is, however, not required when the result is unused. If we still need to emit the check (due to consumer arguments), let's not emit the memset to zero out the result if it's unused. This fixes a use-after-scope false positive with AddressSanitizer.
Differential Revision: https://reviews.llvm.org/D34834
llvm-svn: 306838
Summary:
Operator new interceptors behavior is now controlled by their nothrow
property as well as by allocator_may_return_null flag value:
- allocator_may_return_null=* + new() - die on allocation error
- allocator_may_return_null=0 + new(nothrow) - die on allocation error
- allocator_may_return_null=1 + new(nothrow) - return null
Ideally new() should throw std::bad_alloc exception, but that is not
trivial to achieve, hence TODO.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34731
llvm-svn: 306604
Summary:
On Android we still need to reset preinstalled handlers and allow use handlers later.
This reverts commit r304039.
Reviewers: eugenis
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D34434
llvm-svn: 305871
Summary:
ASan shadow memory on s390 is larger than other configurations, let's
disable this test for now (will revisit it later).
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34414
llvm-svn: 305822
Summary:
Point of failure is different after D34243, hence the change of the
message.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34292
llvm-svn: 305580
Summary:
Context: https://github.com/google/sanitizers/issues/740.
Making secondary allocator to respect allocator_may_return_null=1 flag
and return nullptr when "out of memory" happens.
More changes in primary allocator and operator new will follow.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34243
llvm-svn: 305569
Summary:
After r303941 it was not possible to setup ASAN_OPTIONS to have the same
behavior for pre r303941 and post r303941 builds.
Pre r303941 Asan does not accept handle_sigbus=2.
Post r303941 Asan does not accept allow_user_segv_handler.
This fix ignores allow_user_segv_handler=1, but for allow_user_segv_handler=0
it will upgrade flags like handle_sigbus=1 to handle_sigbus=2. So user can set
ASAN_OPTIONS=allow_user_segv_handler=0 and have same behavior on old and new
clang builds (except range from r303941 to this revision).
In future users which need to prevent third party handlers should switch to
handle_sigbus=2 and remove allow_user_segv_handler as soon as suport of older
builds is not needed.
Related bugs:
https://github.com/google/oss-fuzz/issues/675https://bugs.chromium.org/p/chromium/issues/detail?id=731130
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34227
llvm-svn: 305433
This patch addresses PR 33206. There might be a situation when dynamic ASan runtime initializes later
than shared library which has malloc in static constructor (rtld doesn't provide an order of shared libs initialization).
In this case ASan hasn't yet initialized interceptors, but already intercepts malloc.
If malloc is too big to be handled by static local pool, ASan will die with error:
Sanitizer CHECK failed: lib/asan/asan_malloc_linux.cc:40 ((allocated_for_dlsym)) < ((kDlsymAllocPoolSize)) (1036, 1024)
Patch by Denis Khalikov.
Differential Revision: https://reviews.llvm.org/D33784
llvm-svn: 305058
Summary:
As mentioned in test/msan/fork.cc, if test output is redirected to a file
(as opposed to being piped directly to FileCheck), we may lose some "done"s due to
a kernel bug: https://lkml.org/lkml/2014/2/17/324, so let's pipe the
output of the test.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33915
llvm-svn: 304744
Summary:
halt_on_error-torture.cc intermittently fails on ppc64be, let's try to
collect more info on failures.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33912
llvm-svn: 304731
atos is apparently not able to resolve symbol addresses properly on
i386-darwin reliably any more. This is causing bot flakiness:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/6841
There have not been any SDK changes on the bot as of late.
/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/llvm/projects/compiler-rt/test/asan/TestCases/Darwin/atos-symbolizer.cc:20:12: error: expected string not found in input
// CHECK: #1 0x{{.*}} in main {{.*}}atos-symbolizer.cc:[[@LINE-4]]
^
<stdin>:35:27: note: scanning from here
#0 0x112f56 in wrap_free (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/lib/clang/5.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:i386+0x56f56)
^
<stdin>:35:27: note: with expression "@LINE-4" equal to "16"
#0 0x112f56 in wrap_free (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/lib/clang/5.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:i386+0x56f56)
^
<stdin>:36:168: note: possible intended match here
#1 0xb6f20 in main (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/tools/clang/runtime/compiler-rt-bins/test/asan/I386DarwinConfig/TestCases/Darwin/Output/atos-symbolizer.cc.tmp:i386+0x1f20)
llvm-svn: 304674
Summary:
D33521 addressed a memory ordering issue in BlockingMutex, which seems
to be the cause of a flakiness of a few ASan tests on PowerPC.
Reviewers: eugenis
Subscribers: kubamracek, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33611
llvm-svn: 304045
Summary:
D33521 addressed a memory ordering issue in BlockingMutex, which seems
to be the cause of a flakiness of a few ASan tests on PowerPC.
Reviewers: eugenis
Subscribers: kubamracek, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33569
llvm-svn: 303995
Summary:
allow_user_segv_handler had confusing name did not allow to control behavior for
signals separately.
Reviewers: eugenis, alekseyshl, kcc
Subscribers: llvm-commits, dberris, kubamracek
Differential Revision: https://reviews.llvm.org/D33371
llvm-svn: 303941
This test case occassionally fails when run on powerpc64 be.
asan/TestCases/Posix/halt_on_error-torture.cc
The failure causes false problem reports to be sent to developers whose
code had nothing to do with the failures. Reactivate it when the real
problem is fixed.
This could also be related to the same problems as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, ManyThreadsTest,
and several others that do not run reliably on powerpc.
llvm-svn: 303864
Summary: We are going to make it tri-state and remove allow_user_segv_handler.
Reviewers: eugenis, alekseys, kcc
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D33159
llvm-svn: 303464
Our theory is that reserving large amounts of shadow memory isn't
reliable on Win7 and earlier NT kernels. This affects the
clang-x64-ninja-win7 buildbot, which uses Windows 7.
llvm-svn: 302917
Summary:
glibc on Linux calls __longjmp_chk instead of longjmp (or _longjmp) when
_FORTIFY_SOURCE is defined. Ensure that an ASAN-instrumented program
intercepts this function when a system library calls it, otherwise the
stack might remain poisoned and result in CHECK failures and false
positives.
Fixes https://github.com/google/sanitizers/issues/721
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D32408
llvm-svn: 302152
This patch marks a few ASan tests as unsupported on iOS. These are mostly tests that use files or paths that are invalid/inaccessible on iOS or the simulator. We currently don't have a good way of propagating/copying secondary files that individual tests need. The same problem exists on Android, so I'm just marking the tests as UNSUPPORTED now.
Differential Revision: https://reviews.llvm.org/D32632
llvm-svn: 301966
These test cases occassionally fail when run on powerpc64le:
ignore_lib1.cc
ignore_lib5.cc
TestCases/Posix/current_allocated_bytes.cc
rtl/TsanRtlTest/Posix.ThreadLocalAccesses
TestCases/Posix/coverage-fork-direct.cc
The failures cause false problem reports to be sent to developers whose
code had nothing to do with the failures. Reactivate them when the real
problems are fixed.
This could also be related to the same problems as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, ManyThreadsTest,
and several others that do not run reliably on powerpc.
llvm-svn: 301798
Tests that run on the iOS simulator require the dlopen'd dylibs are codesigned. This patch adds the "iossim_compile.py" wrapper that codesigns any produces dylib.
Differential Revision: https://reviews.llvm.org/D32561
llvm-svn: 301617
This patch adds "%env" as a way to express that the environment variable should be set on the target device/simulator. This fixes some test failures when testing on iOS/Simulator.
Differential Revision: https://reviews.llvm.org/D32556
llvm-svn: 301462
This patch adds a basic support for running the ASan lit test suite against an iOS Simulator. This is done by generating more lit.site.cfg configurations into subdirectories such as IOSSimI386Config and IOSSimX86_64Config. These test suites are not added into "check-all" or into "check-asan", they have to be run manually.
Differential Revision: https://reviews.llvm.org/D31477
llvm-svn: 301443
Summary:
strchr interceptor does not need to call strlen if strict_string_checks is not
enabled. Unnecessary strlen calls affect python parser performance.
Reviewers: eugenis, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D32264
llvm-svn: 301027
At least one of the ARM bots is still broken:
Command Output (stderr):
--
/home/buildslave/buildslave/clang-cmake-armv7-a15-full/llvm/projects/compiler-rt/test/asan/TestCases/Posix/strchr.c:31:12: error: expected string not found in input
// CHECK: strchr.c:[[@LINE-2]]
^
<stdin>:3:59: note: scanning from here
==16297==ERROR: AddressSanitizer: SEGV on unknown address 0xb5add000 (pc 0xb6dccaa4 bp 0xbe8c19c8 sp 0xbe8c1570 T0)
^
<stdin>:3:59: note: with expression "@LINE-2" equal to "29"
==16297==ERROR: AddressSanitizer: SEGV on unknown address 0xb5add000 (pc 0xb6dccaa4 bp 0xbe8c19c8 sp 0xbe8c1570 T0)
^
<stdin>:5:57: note: possible intended match here
#0 0xb6dccaa3 in strlen /build/glibc-f8FFOS/glibc-2.23/string/../sysdeps/arm/armv6t2/strlen.S:82
Try to fix by reverting r300889 and subsequent fixes:
Revert "[asan] Fix test by removing "The signal is caused" check."
Revert "[asan] Fix test on ppc64le-linux by checking "UNKNOWN memory access""
Revert "[asan] Match BUS and SIGV to fix test on Darwin"
Revert "[asan] Optimize strchr for strict_string_checks=false"
llvm-svn: 300955
Summary:
The textdomain function accepts a NULL parameter (and should then return the
current message domain). Add a check for this and include ASAN tests.
Link: https://github.com/google/sanitizers/issues/787
Reviewers: m.guseva, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D32318
llvm-svn: 300924
Summary:
strchr interceptor does not need to call strlen if strict_string_checks is not
enabled. Unnecessary strlen calls affect python parser performance.
Reviewers: eugenis, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D32264
llvm-svn: 300889
There are two cases to consider:
We are using the internal shell. This will still fail because of
ulimit.
We are using an external shell. In this case the difference is that we
now also constrain FileCheck to use less than 4 MB of of stack, which
it should :-)
llvm-svn: 299586
This works with a regular shell since the kernel can keep track of a
deleted cwd. Since we just keep a path string, the following
subprocess invocations fail.
I think this would also fail on windows.
llvm-svn: 299471
The patch addresses https://github.com/google/sanitizers/issues/786. Currently AsanCheckDynamicRTPrereqs prevents
dynamic ASan runtime from running in some important environments e.g. cowbuilder and fakeroot that may also work with interposition.
Let's allow users to switch off the check given that they know what they do.
Differential Revision: https://reviews.llvm.org/D31420
llvm-svn: 299188
AddressSanitizer has an optional compile-time flag, -fsanitize-address-use-after-scope, which enables detection of use-after-scope bugs. We'd like to have this feature on by default, because it is already very well tested, it's used in several projects already (LLVM automatically enables it when using -DLLVM_USE_SANITIZER=Address), it's low overhead and there are no known issues or incompatibilities.
This patch enables use-after-scope by default via the Clang driver, where we set true as the default value for AsanUseAfterScope. This also causes the lifetime markers to be generated whenever fsanitize=address is used. This has some nice consequences, e.g. we now have line numbers for all local variables.
Differential Revision: https://reviews.llvm.org/D31479
llvm-svn: 299175
{M, T, E}San have fread and fwrite interceptors, let's move them to sanitizer_common to enable ASan checks as well.
Differential Revision: https://reviews.llvm.org/D31456
llvm-svn: 299061
When -fsanitize-address-use-after-scope is used, the instrumentation produces line numbers in stack frame descriptions. This patch make sure the ASan runtime supports this format (ParseFrameDescription needs to be able to parse "varname:line") and prepares lit tests to allow line numbers in ASan report output.
Differential Revision: https://reviews.llvm.org/D31484
llvm-svn: 299043
Summary:
I know of two implementations that do this (ASan is not protecting against accessing the returned memory for now, just like malloc(0)):
SIE libc on the PS4
dlmalloc has a flag for this
This allows us to properly support this behaviour.
Reviewers: vsk, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31295
llvm-svn: 299016
This is failing on some of our internal bots because we're using different symbolizers. It doesn't seem important and we never test for column numbers in any other tests, so let's just remove it.
Differential Revision: https://reviews.llvm.org/D30122
llvm-svn: 298822
Asserting the result of strtok when we expect delimiter overflow is
flaky, the result depends on the random state of memory right after the
delimiters.
llvm-svn: 298743
Summary:
This change addresses https://github.com/google/sanitizers/issues/766. I
tested the change with make check-asan and the newly added test case.
Reviewers: ygribov, kcc, alekseyshl
Subscribers: kubamracek, llvm-commits
Patch by mrigger
Differential Revision: https://reviews.llvm.org/D30384
llvm-svn: 298650
Revert "Fix sanitizer tests with LLVM_TOOL_LLD_BUILD=OFF."
Revert "[asan] Remove gc-sections test with bfd."
Revert "[asan] Disable globals-gc test with ld.bfd."
Revert "[asan] Fix dead stripping of globals on Linux (compiler-rt)"
OOM in gold linker.
llvm-svn: 298287
It used to be XFAIL: *, but with the new implementation it passes in some cases
and fails in other. There are similar tests for gold and lld that are not
flaky, and a positive test for bfd that makes sure that were are not breaking
existing functionality.
llvm-svn: 298173
Runtime support for the new instrumentation of globals based on !associated, and a bunch of tests.
Differential Revision: https://reviews.llvm.org/D30120
llvm-svn: 298159
Summary: This is useful in some platforms where one of these signals is special.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30783
llvm-svn: 297665
Summary:
Asan is now working on windows 64-bit.
This patch is turning on the unittest.
Reviewers: rnk
Reviewed By: rnk
Subscribers: kubamracek, dberris, beanz, mgorny, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24742
llvm-svn: 296878
Summary:
The current size is flaky, as revealed by checking
the stack size attr after setting it.
Reviewers: kubamracek, rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30267
llvm-svn: 296706
Summary: Points the user to look at function pointer assignments.
Reviewers: kcc, eugenis, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30432
llvm-svn: 296653
Summary: Points the user to look at function pointer assignments.
Reviewers: kcc, eugenis, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30432
llvm-svn: 296419
Summary: On windows 10, the ucrt DLL is performing allocations before the function hooking and there are multiple allocations not handled by Asan. When a free occur at the end of the process, asan is reporting desallocations not malloc-ed.
Reviewers: rnk, kcc
Reviewed By: rnk, kcc
Subscribers: kcc, llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D25946
llvm-svn: 295730
Summary:
There is no guarantee that the tls_init is executed on the static runtime
(/MT).
On windows 7, this unittest is failing.
On windows 10, I believe it's working because of the new CRT.
On ASAN side, it doesn't matter that the hook point is run or not.
It must be run only if there is other tls_initializer that are registered.
Reviewers: rnk, chrisha
Reviewed By: rnk
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D29838
llvm-svn: 295057
Add support for weak hooks on Windows, as we do on Linux and Darwin.
As we use the macro: `SANITIZER_INTERFACE_WEAK_DEF()` it was not necessary to
modify the header file: `sanitizer_common_interceptors.h`.
After this diff, many tests were fixed for libFuzzer.
Differential Revision: https://reviews.llvm.org/D29562
llvm-svn: 294409
In this diff I update the code for asan on Windows, so we can intercept
SetUnhandledExceptionFilter and catch some exceptions depending on the result of
IsHandledDeadlyException() (which depends on asan flags).
This way we have the same behavior on Windows and Posix systems.
On Posix, we intercept signal and sigaction, so user's code can only register
signal handlers for signals that are not handled by asan.
After this diff, the same happens on Windows, user's code can only register
exception handlers for exceptions that are not handled by asan.
Differential Revision: https://reviews.llvm.org/D29463
llvm-svn: 293957
We ignore `__ubsan_handle_dynamic_type_cache_miss*` symbols when
`SANITIZER_CAN_USE_CXXABI` is true. Because they are included in the
library but they are not included in the interface lists.
llvm-svn: 293711
The test was failing because we export the functions: "__sanitizer_mz*" but they
are not included in the general interface lists.
Also, weak undefined symbols are tagged with U by `nm -g` on Darwin.
Differential Revision: https://reviews.llvm.org/D29345
llvm-svn: 293710
Add a new auxiliary file to each sanitizer: sanitizer_interface.inc, listing all
the functions exported, with the macros: INTERFACE_FUNCTION() and
INTERFACE_WEAK_FUNCTION().
So, when we need to define or repeat a procedure for each function in the
sanitizer's interface, we can define the macros and include that header.
In particular, these files are needed for Windows, in the nexts commits.
Also, this files could replace the existing files: weak_symbols.txt for Apple.
Instead of reading weak_symbols.txt to get the list of weak symbols, we could
read the file sanitizer_interface.inc and consider all the symbols included with
the macro INTERFACE_WEAK_FUNCTION(Name).
In this commit, I only include these files to the sanitizers that work on
Windows. We could do the same for the rest of the sanitizers when needed.
I updated tests for: Linux, Darwin and Windows. If a new function is exported
but is not present in the interface list, the tests
"interface_symbols_[darwin|windows|linux].c" fail.
Also, I remove the comments: "/* OPTIONAL */" which are not required any more,
because we use the macro: INTERFACE_WEAK_FUNCTION() for weak functions.
Differential Revision: https://reviews.llvm.org/D29148
llvm-svn: 293682
macOS
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Also delete the non-functional `cfree` wrapper for Windows, to fix the
test cases on that platform.
Reviewers: emaste, kcc, rnk
Subscribers: timurrrr, eugenis, hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
llvm-svn: 293536
Add "OPTIONAL" comment to declaration of weak function in the internal
interface. This fix the tests `interface_symbols_linux.c` and
`interface_symbols_darwin.c` which were failing after r293423.
llvm-svn: 293442
In this diff, I define a general macro for defining weak functions
with a default implementation: "SANITIZER_INTERFACE_WEAK_DEF()".
This way, we simplify the implementation for different platforms.
For example, we cannot define weak functions on Windows, but we can
use linker pragmas to create an alias to a default implementation.
All of these implementation details are hidden in the new macro.
Also, as I modify the name for exported weak symbols on Windows, I
needed to temporarily disable "dll_host" test for asan, which checks
the list of functions included in asan_win_dll_thunk.
Differential Revision: https://reviews.llvm.org/D28596
llvm-svn: 293419
This reverts r293337, which breaks tests on Windows:
malloc-no-intercept-499eb7.o : error LNK2019: unresolved external symbol _mallinfo referenced in function _main
llvm-svn: 293346
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Reviewers: emaste, kcc
Subscribers: hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
llvm-svn: 293337
Breaks tests on i686/Linux due to missing clang driver support:
error: unsupported option '-fsanitize=leak' for target 'i386-unknown-linux-gnu'
llvm-svn: 292844
People keep asking LSan to be available on 32 bit targets (e.g. https://github.com/google/sanitizers/issues/403)
despite the fact that false negative ratio might be huge (up to 85%). This happens for big real world applications
that may contain random binary data (e.g. browser), but for smaller apps situation is not so terrible and LSan still might be useful.
This patch adds initial support for x86 Linux (disabled by default), ARM32 is in TODO list.
We used this patch (well, ported to GCC) on our 32 bit mobile emulators and it worked pretty fine
thus I'm posting it here to initiate further discussion.
Differential Revision: https://reviews.llvm.org/D28609
llvm-svn: 292775
Running lit tests and unit tests of ASan and TSan on macOS has very bad performance when running with a high number of threads. This is caused by xnu (the macOS kernel), which currently doesn't handle mapping and unmapping of sanitizer shadow regions (reserved VM which are several terabytes large) very well. The situation is so bad that increasing the number of threads actually makes the total testing time larger. The macOS buildbots are affected by this. Note that we can't easily limit the number of sanitizer testing threads without affecting the rest of the tests.
This patch adds a special "group" into lit, and limits the number of concurrently running tests in this group. This helps solve the contention problem, while still allowing other tests to run in full, that means running lit with -j8 will still with 8 threads, and parallelism is only limited in sanitizer tests.
Differential Revision: https://reviews.llvm.org/D28420
llvm-svn: 292549
Summary:
There are cases when thread local quarantine drains almost empty
quarantine batches into the global quarantine. The current approach leaves
them almost empty, which might create a huge memory overhead (each batch
is 4K/8K, depends on bitness).
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28068
llvm-svn: 292525
Running lit tests and unit tests of ASan and TSan on macOS has very bad performance when running with a high number of threads. This is caused by xnu (the macOS kernel), which currently doesn't handle mapping and unmapping of sanitizer shadow regions (reserved VM which are several terabytes large) very well. The situation is so bad that increasing the number of threads actually makes the total testing time larger. The macOS buildbots are affected by this. Note that we can't easily limit the number of sanitizer testing threads without affecting the rest of the tests.
This patch adds a special "group" into lit, and limits the number of concurrently running tests in this group. This helps solve the contention problem, while still allowing other tests to run in full, that means running lit with -j8 will still with 8 threads, and parallelism is only limited in sanitizer tests.
Differential Revision: https://reviews.llvm.org/D28420
llvm-svn: 292232
Summary:
Bypass quarantine altogether when quarantine size is set ot zero.
Also, relax atomic load/store of quarantine parameters, the
release/acquire semantics is an overkill here.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D28586
llvm-svn: 291791
Bill Seurer