Only tests using %clang_cl_asan were using the dynamic CRT before this.
The unit tests and lit tests using %clangxx_asan were using the static
CRT. Many cross-platform tests fail with the dynamic CRT, so I had to
add win32-(static|dynamic)-asan lit features.
Also deletes some redundant tests in TestCases/Windows that started
failing with this switch.
llvm-svn: 285821
On Darwin, simple C null-terminated constant strings normally end up in the __TEXT,__cstring section of the resulting Mach-O binary. When instrumented with ASan, these strings are transformed in a way that they cannot be in __cstring (the linker unifies the content of this section and strips extra NUL bytes, which would break instrumentation), and are put into a generic __const section. This breaks some of the tools that we have: Some tools need to scan all C null-terminated strings in Mach-O binaries, and scanning all the contents of __const has a large performance penalty. This patch instead introduces a special section, __asan_cstring which will now hold the instrumented null-terminated strings.
Differential Revision: https://reviews.llvm.org/D25026
llvm-svn: 285620
ASan dead-strip support relies on a linker option that only exists
in 10.11 and later, so the LLVM instrumentation checks for the deployment
target. This test does not pass when clang is built to choose lower
deployment target by default but runs on newer host.
(Note, the REQUIRES: osx-ld64-live_support clause only checks the host
and not the target OS.)
Differential Revision: https://reviews.llvm.org/D26107
llvm-svn: 285482
There is possible deadlock in dynamic ASan runtime when we dlopen() shared lib
which creates a thread at the global initialization stage. The scenario:
1) dlopen grabs a GI_pthread_mutex_lock in main thread.
2) main thread calls pthread_create, ASan intercepts it, calls real pthread_create
and waits for the second thread to be "fully initialized".
3) Newly created thread tries to access a thread local disable_counter in LSan
(to complete its "full initialization") and hangs in tls_get_addr_tail, because
it also tries to acquire GI_pthread_mutex_lock.
The issue is reproducible on relative recent Glibc versions e.g. 2.23.
Differential Revision: https://reviews.llvm.org/D26028
llvm-svn: 285385
Darwin's implementation of strstr seems to trigger slightly different failure
modes from Linux since it calls strncmp. All messages seem about equally useful
and correct, so I relaxed the tests so Darwin can pass.
llvm-svn: 285004
Summary:
This test is broken on wndows 64-bit.
The interception library is not able to hook on the memchr functions.
Snippet of the function that is not hookable:
```
--- No source file -------------------------------------------------------------
000007FEFA1A18CD CC int 3
000007FEFA1A18CE CC int 3
000007FEFA1A18CF CC int 3
--- f:\dd\vctools\crt\vcruntime\src\string\amd64_arm_arm64\memchr.c ------------
while ( cnt && (*(unsigned char *)buf != (unsigned char)chr) ) {
000007FEFA1A18D0 4D 85 C0 test r8,r8
000007FEFA1A18D3 74 0D je memchr+12h (07FEFA1A18E2h)
000007FEFA1A18D5 38 11 cmp byte ptr [rcx],dl
000007FEFA1A18D7 74 09 je memchr+12h (07FEFA1A18E2h)
buf = (unsigned char *)buf + 1;
000007FEFA1A18D9 48 FF C1 inc rcx
cnt--;
000007FEFA1A18DC 49 83 E8 01 sub r8,1
000007FEFA1A18E0 75 F3 jne memchr+5h (07FEFA1A18D5h)
}
```
Reviewers: rnk
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D25037
llvm-svn: 282860
Summary:
On windows, the memcpy and memmove function can be the same.
This is correcly detected when hooking, but it's not possible
to report the right function name when doing symbolisation.
The same fix was applied for the static asan unittest.
We forgot to apply the fix for the dynamic asan tests.
```
lvm\projects\compiler-rt\test\asan/TestCases/Windows/.svn/text-base/intercept_memcpy.cc.svn-base:// CHECK-NEXT: __asan_{{.*}}mem{{.*}}
```
This patch is fixing this test (win64):
```
ddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
```
Reviewers: rnk, vitalybuka
Subscribers: llvm-commits, kubabrecka, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D25038
llvm-svn: 282859
This patch extends __sanitizer_finish_switch_fiber method to optionally return previous stack base and size.
This solves the problem of coroutines/fibers library not knowing the original stack context from which the library is used. It's incorrect to assume that such context is always the default stack of current thread (e.g. one such library may be used from a fiber/coroutine created by another library). Bulding a separate stack tracking mechanism would not only duplicate AsanThread, but also require each coroutines/fibers library to integrate with it.
Author: Andrii Grynenko (andriigrynenko)
Reviewed in: https://reviews.llvm.org/D24628
llvm-svn: 282582
Summary:
I need to redu solution, existing is not good enough.
PR28267
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24490
llvm-svn: 281687
The '-asan-use-private-alias’ option (disabled by default) option is currently only enabled for Linux and ELF, but it also works on Darwin and Mach-O. This option also fixes a known problem with LTO on Darwin (https://github.com/google/sanitizers/issues/647). This patch enables the support for Darwin (but still keeps it off by default) and adds the LTO test case.
Differential Revision: https://reviews.llvm.org/D24292
llvm-svn: 281472
When running with start_deactivated=1 in ASAN_OPTIONS, heap redzones
are not poisoned until the first instrumented module is loaded. This
can cause false negatives even on memory allocated after activation,
because redzones are normally poisoned only once when a new allocator
region is mapped.
This change attempts to fix it by iterating over all existing
allocator chunks and poisoning their redzones.
llvm-svn: 281364
The same thing is already done on Mac. handle_abort slows down tests
significantly because it triggers tombstone collection on Android;
also, it changes failed test outcome from "not-crash" to "crash" (as
in "bin/not --crash").
This change adds handle_abort=0 to asan options on android (test
only!), and also tweaks android_run.py to semi-correctly pass the
crash/no-crash status to the caller.
llvm-svn: 281075
Summary: Merges back both scariness_score_test.cc files, since the Linux-specific version shouldn't be needed any more.
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24347
llvm-svn: 281048
Reset the SIGABRT signal handler before calling abort().
Also, change the error message when catching SIGABRT to say "ABRT"
instead of "SEGV".
llvm-svn: 280885
Summary:
Only one of the tests in it doesn't work on OS X.
On Windows it seems that everything that is being moved is also
supported.
The abort() test wasn't copied over (original case 22). This is because
it doesn't work on OS X.
Reviewers: kcc, eugenis, vitalybuka
Subscribers: kubabrecka, llvm-commits
llvm-svn: 280469
The abort() test wasn't copied over (original case 22). This is because
it doesn't work on OS X.
If theres no buildbot problem with this test later today, I will
minimize the Linux version.
llvm-svn: 280361
Summary:
We are going to use store instructions to poison some allocas.
Runtime flag will require branching in instrumented code on every lifetime
intrinsic. We'd like to avoid that.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23967
llvm-svn: 279981
and x86_64h-apple.
Mark the test as UNSUPPORTED to fix a bot that is failing.
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check
The bot is failing because asan_symbolize.py cannot tell whether the
reported address is from an x86_64 slice or an x86_64h slice by the
length of the address alone, so it ends up passing the wrong arch to
atos.
rdar://problem/27907889
llvm-svn: 279614
The mips64el compiler-rt build has recently been enabled. XFAIL the failing
tests to make the buildbot green again.
The two asan tests require the integrated assembler. This will be fixed soon
for Debian mips64el but not for any other mips64el targets since doing so
requires triple-related issues to be fixed..
The msan tests are largely failing because caused by a kernel update (a patch
has already been posted for this).
I'm not sure why the dfsan test fails yet.
llvm-svn: 278504
Go back to intercepting kernel32!RaiseException, and only go for
ntdll!RtlRaiseException if that fails. Fixes throw_and_catch.cc test.
Work around an issue in LLVM's win64 epilogues. We end up with an
epilogue that looks like this, and it drives the Win64 unwinder crazy
until stack overflow:
call ill_cc!__asan_handle_no_return
xor eax,eax
add rsp,40h // epilogue starts
pop rbp // CSR
ud2 // Trap here
ret // Ret?
nop word ptr [rax+rax]
sub rsp,28h // Next function
Will file a PR soon.
llvm-svn: 277874
Summary:
Respect the handle_sigill common flag and handle_segv flags while we're
at it.
We still handle signals/exceptions differently on Unix and Windows. The
installation process is tricky on Windows, and difficult to push down
into sanitizer_common without concerning it with the different
static/dynamic CRT models on Windows.
Reviewers: kcc, etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23098
llvm-svn: 277621
Summary:
On my install of Windows 10, RaiseException is a tail call to
kernelbase!RaiseException. Obviously, we fail to intercept that.
Instead, try hooking at the ntdll!RtlRaiseException layer. It is
unlikely that this layer will contain control flow.
Intercepting at this level requires adding a decoding for
'LEA ESP, [ESP + 0xXXXXXXXX]', which is a really obscure way to write
'SUB ESP, 0xXXXXXXXX' that avoids clobbering EFLAGS.
Reviewers: etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23046
llvm-svn: 277518
We no longer assign ids to unregistered threads. We don't have any stack
trace for thread creation for these worker threads, so this shouldn't
affect report quality much.
llvm-svn: 277514
Summary:
On Windows 10, this gets called after TLS has been torn down from NTDLL,
and we crash attempting to return fake_tsd. This interceptor isn't
needed after r242948 anyway, so let's remove it. The ASan runtime can
now tolerate unregistered threads calling __asan_handle_no_return.
Reviewers: vitalybuka, etienneb
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23044
llvm-svn: 277478
When we run halt_on_error-torture.cc with 10 threads and 20 iterations with halt_on_error=false:suppress_equal_pcs=false, we write 200 reports to 10.txt file and sometimes have collisions.
We have CHECK-COLLISION check that greps 'AddressSanitizer: nested bug in the same thread, aborting' message in 10.txt, but it doesn't contain this line.
If I don't redirect stderr > 10.txt 'AddressSanitizer: nested bug in the same thread, aborting' is printed to my screen as expected.
Same happens for halt_on_error_suppress_equal_pcs.cc and halt_on_error-torture.cc. This happens because of kernel bug: https://lkml.org/lkml/2014/2/17/324
Furtunately, we can fix these tests by implicitly setting O_APPEND for opened files (use >> instead of > for stderr redirection).
Differential Revision: https://reviews.llvm.org/D22921
llvm-svn: 277324
Summary:
Test where broken because of missing lifetime markers for temps and
because of aggressive optimization which removed markers in some cases.
PR27453
Reviewers: eugenis, kcc
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D22894
llvm-svn: 277074
Add a %stdcxx11 lit substitution for -std=c++11. Windows defaults to
-std=c++14 when VS 2015 is used because the STL requires it. Harcoding
-std=c++11 in the ASan tests actually downgrades the C++ standard level,
leading to test failures.
Relax a FileCheck pattern in use-after-scope-types.cc.
Disable the sanitizer_common OOM tests. They fail on bots with low swap,
and cause other concurrently running tests to OOM.
llvm-svn: 276454
The OOM test should really only run on 32-bits, since it's hard to OOM
on x64.
The operator_array_new_with_dtor_left_oob tests need to account for the
larger array cookie on x64 (8 bytes instead of 4).
Use -std=c++14 in use-after-scope-capture.cc to avoid errors in the MSVC
2015 STL on Windows. The default there is C++14 anyway.
llvm-svn: 276332
Summary:
This patch is fixing running interception unittests for memcpy/memmove on
windows 64.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22641
llvm-svn: 276324
Summary:
These unittests are not running on windows because they are using incorrect commands.
They were not failing on 32-bits because there is a requirement: asan-64-bits.
```
$ "nm" "C:\src\llvm\ninja64\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\no_asan_gen_globals.c.tmp.exe"
# command stderr:
'nm': command not found
error: command failed with exit status: 127
```
```
$ "rm" "-rf" "C:\src\llvm\ninja64\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output/coverage-tracing"
$ "mkdir" "C:\src\llvm\ninja64\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output/coverage-tracing"
$ "A=x"
# command stderr:
'A=x': command not found
error: command failed with exit status: 127
```
```
$ "DIR=C:\src\llvm\ninja64\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output/coverage-order-pcs"
# command stderr:
'DIR=C:\\src\\llvm\\ninja64\\projects\\compiler-rt\\test\\asan\\X86_64WindowsConfig\\TestCases\\Output/coverage-order-pcs': command not found
error: command failed with exit status: 127
```
Reviewers: rnk
Subscribers: tberghammer, llvm-commits, danalbert, wang0109, srhines, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22612
llvm-svn: 276290
Summary:
This is an other tentative to fix:
https://reviews.llvm.org/D22588
It's less clever, but should work.
Turn out there is not an easy way to write a portable print
for a pointer in lowercase without the prefix 0x.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22606
llvm-svn: 276286
Summary:
By adding the initialisation of the symbolisation library (DbgHelp)
we are swapping the order in which both warnings are produced.
We can't use CHECK-NEXT as the dbghelp warning is multiline.
Reviewers: rnk
Subscribers: kubabrecka, llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22586
llvm-svn: 276228
Summary:
The printf is not working correctly on 64-bit MSVC.
The portable way to print "size_t" is to use "%zx" (size_t in hexa).
Reviewers: rnk
Subscribers: kubabrecka, llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22588
llvm-svn: 276179
Summary:
This test is allocating a 1gig chunk to make shadow allocation failed,
but on 64-bits architecture the test is working.
Reviewers: rnk
Subscribers: kubabrecka, llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22553
llvm-svn: 276122
Summary: This flag could be used to disable check in runtime.
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D22495
llvm-svn: 276004
Summary:
Avoid mismatch between imports/exports for 32-bit and 64-bits version.
The test is running grep over macros to detect which functions are
intercepted. Unfortunately, exception handlers differ in 32-bit and
64-bit.
This patch is removing the exception handlers from the test.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22484
llvm-svn: 275982
It seems in some situations we have clashes on very first error so test only prints "nested bug in the same thread, aborting" rather than "use-after-poison", so remove corresponding " RUN: FileCheck %s < 10.txt" line.
Also, the two last " RUN: FileCheck --check-prefix=CHECK-COLLISION %s < 1.txt || FileCheck --check-prefix=CHECK-NO-COLLISION %s < 1.txt" look wrong, they should check 10.txt. Fix these lines too.
Differential Revision: https://reviews.llvm.org/D22309
llvm-svn: 275539
Summary:
Both test have the same command-line.
The second test is missing the /GS-.
Keep in mind that /GS is on by default.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22339
llvm-svn: 275491
Summary:
When test was added we had no -fsanitize-address-use-after-scope in clang
so we had to use -mllvm -asan-use-after-scope=1.
Reviewers: eugenis
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D22382
llvm-svn: 275475
These test in this change are objc++, but are built using %clang, not %clangxx.
The reason this works is the driver has been adding -lc++ for sanitizer enabled
builds. By making these tests use %clangxx, they no longer depend on the driver
linking to c++. Doing so will allow us to prevent overlinking of libc++ for
applications.
llvm-svn: 274989
See the bug report at https://github.com/google/sanitizers/issues/691. When a dynamic alloca has a constant size, ASan instrumentation will treat it as a regular dynamic alloca (insert calls to poison and unpoison), but the backend will turn it into a regular stack variable. The poisoning/unpoisoning is then broken. This patch will treat such allocas as static.
Differential Revision: http://reviews.llvm.org/D21509
llvm-svn: 273889
This test is flaky. Specifically, on some Mac configurations we see the
__sanitizer_ptr_cmp as the 0th frame. Let's relax it to not require that
f is in frame #0.
61396==ERROR: AddressSanitizer: invalid-pointer-pair: 0x01e00510 0x01e004d0
0 0x18f5a3 in __sanitizer_ptr_cmp ... libclang_rt.asan_osx_dynamic.dylib+0xaf5a3)
1 0xdd924 in f(char, char*, char*) ... invalid-pointer-pairs.cc:14:14
Differential Revision: http://reviews.llvm.org/D21588
llvm-svn: 273475
This test case checks that globals from all object files are being registered
after they've been linked together. It also checks that globals from libraries
loaded at runtime are registered.
llvm-svn: 273464
This patch adds the __sanitizer_start_switch_fiber and
__sanitizer_finish_switch_fiber methods inspired from what can be found here
2ea64dd249 .
These methods are needed when the compiled software needs to implement
coroutines, fibers or the like. Without a way to annotate them, when the program
jumps to a stack that is not the thread stack, __asan_handle_no_return shows a
warning about that, and the fake stack mechanism may free fake frames that are
still in use.
Author: blastrock (Philippe Daouadi)
Reviewed in http://reviews.llvm.org/D20913
llvm-svn: 273260
Reid Kleckner