Make kStderrFd a macro to avoid dynamic initialization of the
report_file global. This actually causes a crash at runtime, because
ASan initializes before static initializers run.
Remove an unused variable in asan_win.cc.
llvm-svn: 276314
Summary:
The memcpy and memmove functions are the same on windows.
The overlap detection logic is incorrect.
printf-1 test:
```
stdin>:2:114: note: possible intended match here
==877412==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x0000002bf2a8,0x0000002bf2ad) and [0x0000002bf2a9, 0x0000002bf2ae) overlap
``` ^
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22610
llvm-svn: 276299
Summary: This flag could be used to disable check in runtime.
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D22495
llvm-svn: 276004
Summary:
This is adding the appropriate suport for exception handling for
64-bits ASAN on windows.
Reviewers: rnk
Subscribers: kubabrecka, llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22395
llvm-svn: 275585
There is not enough padding in front of memchr(), and, the first 6 bytes
contains a branch instruction. Basically the current interception will
not work on memchr().
It was disabled before, but was missing the part to disable it for
INTERCEPT_LIBRARY_FUNCTION.
Patch by Wei Wang
Differential Revision: https://reviews.llvm.org/D22371
llvm-svn: 275494
Summary:
The function wcslen is incorrectly hooked on windows 64-bits.
The interception library is not able to hook without breaking the code.
The function is too small and the interception must be done with
trampoline-hooking which turned out to be incorrect on a small
loop (first few instructions have a backedge).
Reviewers: rnk
Subscribers: wang0109, chrisha, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D22363
llvm-svn: 275488
Summary:
The unittest is not working on windows. The "regexp.h" is not available and
gtest-port won't support regexp with operator '|'.
The test wasn't failing on 32-bits because of this check:
```
if (SANITIZER_WORDSIZE != 64 || ASAN_AVOID_EXPENSIVE_TESTS) return;
```
```
[ RUN ] AddressSanitizer.HugeMallocTest
C:/src/llvm/llvm/utils/unittest/googletest\src/gtest-port.cc(272): error: Failed
Syntax error at index 30 in simple regular expression "is located 1 bytes to the left|AddressSanitizer failed to allocate": '|' is unsupported.
C:/src/llvm/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc(308): error: Death test: Ident((char*)malloc(n_megs << 20))[-1] = 0
Result: died but not with expected error.
Expected: is located 1 bytes to the left|AddressSanitizer failed to allocate
```
See gtest-port.h:
```
#elif GTEST_OS_WINDOWS
// <regex.h> is not available on Windows. Use our own simple regex
// implementation instead.
# define GTEST_USES_SIMPLE_RE 1
```
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D22257
llvm-svn: 275181
Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
Memory will be committed on demand when exception happens while accessing
shadow memeory region.
Patch by: Wei Wang
Differential Revision: http://reviews.llvm.org/D21942
llvm-svn: 275107
[asan] Fix unittest Asan-x86_64-inline-Test crashing on Windows64
REAL(memcpy) was used in several places in Asan, while REAL(memmove) was not used.
This CL chooses to patch memcpy() first, solving the crash for unittest.
The crash looks like this:
projects\compiler-rt\lib\asan\tests\default\Asan-x86_64-inline-Test.exe
=================================================================
==22680==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000000 (pc 0x000000000000 bp 0x0029d555f590 sp 0x0029d555f438 T0)
==22680==Hint: pc points to the zero page.
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: access-violation (<unknown module>)
==22680==ABORTING
Patch by: Wei Wang
Differential Revision: http://reviews.llvm.org/D22232
llvm-svn: 275098
Summary:
The debug information is not present due to a mis named variabl in
the cmake files.
Reviewers: rnk
Subscribers: kubabrecka, wang0109, llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21938
llvm-svn: 274386
Summary:
The build bot is broken because the runtime library doesn't have
debug information.
This is broken due to a recent change:
http://reviews.llvm.org/D21554
Reviewers: rnk
Subscribers: kubabrecka, llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21862
llvm-svn: 274172
Summary:
On windows, the debug information was not present in the unittest executables,
which make them hard to debug.
The Sanitizer Unittests are compiled with a local clang build.
The link pass is also done by calling clang.
This pass is adding the appropriate flags to bring the right debug information
to these executables.
Reviewers: rnk
Subscribers: kubabrecka, llvm-commits, wang0109, chrisha
Differential Revision: http://reviews.llvm.org/D21838
llvm-svn: 274153
Add the two public functions I added in my last commit in asan_win_dll_thunk.cc
Author: blastrock (Philippe Daouadi)
Reviewed in http://reviews.llvm.org/D21557
llvm-svn: 273288
This is part of the effort for asan to support Windows 64 bit.
Patch by Wei Wang
Differential Revision: http://reviews.llvm.org/D21525
llvm-svn: 273270
Summary:
The MSVC compiler complains about implicit conversion of 32-bits constant to
64-bit when using this shiting pattern 1 << (<64-bit expr>).
Reviewers: rnk
Subscribers: kcc, llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21524
llvm-svn: 273267
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
that makes allocation fail. "UL" is 32-bit and shift by 40 will make
the value overflow and become 0.
Patch by Wei Wang
Differential Revision: http://reviews.llvm.org/D21310
llvm-svn: 272689
Removing some preprocessor #if’s in favor of regular if’s. However, we need to declare empty stub functions to avoid linker errors.
Differential Revision: http://reviews.llvm.org/D20911
llvm-svn: 272047
Some known issues are:
When "head" include instructions that involve branching, the "cut and paste" approach may break down in a way that function interception still work but calling back the original function does not work.
The jmp [rip -8] saves some bytes in the "head" but finding the safe zone of 0xCC is not implemented yet. So it may stomp on preceding codes.
The shadow offset is not working yet on Win64. More complexity maybe involved since there are some differences regarding virtual address space between Window 8 and Windows 8.1/10.
Patch by: Wang Wei
Differential Revision: http://reviews.llvm.org/D20884
llvm-svn: 271915
A signal can be delivered after TryLock but before StartReporting in ScopedInErrorReport, causing a deadlock. Fixing this by statically initializing reporting_thread_tid_ to kInvalidTid.
Differential Revision: http://reviews.llvm.org/D20524
llvm-svn: 271256
It's fixing compilation errors. The runtime is not yet working.
Missing features:
OverrideFunction for x64
an equiv function for inline asm (atomic_compare_exchange_strong)
shadow memory offset needs to be adjusted
RoundUpToInstrBoundary for x64
They will be implemented by subsequent patches.
Patch by Wei Wang.
Differential revision: http://reviews.llvm.org/D20455
llvm-svn: 271049
Summary:
Adds *fstat to the common interceptors.
Removes the now-duplicate fstat interceptor from msan/tsan
This adds fstat to asan/esan, which previously did not intercept it.
Resubmit of http://reviews.llvm.org/D20318 with ios build fixes.
Reviewers: eugenis, vitalybuka, aizatsky
Subscribers: zaks.anna, kcc, bruening, kubabrecka, srhines, danalbert, tberghammer
Differential Revision: http://reviews.llvm.org/D20350
llvm-svn: 269981
The previous patch (r269291) was reverted (commented out) because the patch caused leaks that
were detected by LSan and they broke some lit tests. The actual reason was that dlsym allocates
an error string buffer in TLS, and some LSan lit tests are intentionally not scanning TLS for
root pointers. This patch simply makes LSan ignore the allocation from dlsym, because it's
not interesting anyway.
llvm-svn: 269917
There is no frame validity check in the slow unwinder like there is in the fast unwinder due to which lsan reports a leak even for heap allocated coroutine in the test swapcontext.cc. Since mips/linux uses slow unwindwer instead of fast unwinder, the test fails for mips/linux. Therefore adding the checks before unwinding fixes the test for mips/linux.
Reviewed by aizatsky.
Differential: http://reviews.llvm.org/D19961
llvm-svn: 269882
Summary:
Adds *fstat to the common interceptors.
Removes the now-duplicate fstat interceptor from msan/tsan
This adds fstat to asan/esan, which previously did not intercept it.
Reviewers: eugenis, vitalybuka, aizatsky
Subscribers: tberghammer, danalbert, srhines, kubabrecka, bruening, kcc
Differential Revision: http://reviews.llvm.org/D20318
llvm-svn: 269856
http://reviews.llvm.org/rL269291 introduced a memory leak.
Disabling offending call temprorary rather than rolling back the chain
of CLs.
llvm-svn: 269799
Summary:
When using a multi-configuration build (i.e. MSVC) the output path where
libraries are dropped is incorrect.
Example:
```
C:\src\llvm\examples>d:\src\llvm\build\Release\bin\clang-cl.exe -fsanitize=address test.cc
LINK : fatal error LNK1181: cannot open input file 'd:\src\llvm\build\Release\bin\..\lib\clang\3.9.0\lib\windows\clang_rt.asan-i386.lib'
```
The dropped executable path contains the configuration 'Release':
```
'd:\src\llvm\build\Release\bin\..\lib\clang\3.9.0\lib\windows\Release\clang_rt.asan-i386.lib'
```
The variable 'RUNTIME_OUTPUT_DIRECTORY' is used to specify the output directory.
But CMAKE is appending the current configuration (i.e. Debug, Release).
see: https://cmake.org/cmake/help/v3.0/prop_tgt/RUNTIME_OUTPUT_DIRECTORY.html
```
"Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory."
```
To avoid this problem, the configuration specific variable must be set:
'RUNTIME_OUTPUT_DIRECTORY_DEBUG', 'RUNTIME_OUTPUT_DIRECTORY_RELEASE', and so on.
Reviewers: ddunbar, chapuni, rnk
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D20261
llvm-svn: 269658
This patch tries to fix https://llvm.org/bugs/show_bug.cgi?id=27310 by using the same hack for malloc as we use for calloc: allocate corresponding memory from internal buffer when ASan is not initialized.
This way we could avoid nasty '==6987==AddressSanitizer CHECK failed: ../../../../libsanitizer/asan/asan_rtl.cc:556 "((!asan_init_is_running && "ASan init calls itself!")) != (0)" (0x0, 0x0)' errors in
environments with glibc 2.23+ in use, where _dl_signal_error, called from dlsym for undefined symbols calls malloc in order to get a buffer for error message.
Differential Revision: http://reviews.llvm.org/D20235
llvm-svn: 269633
To invoke the Swift demangler, we use dlsym to locate swift_demangle. However, dlsym malloc's storage and stores it in thread-local storage. Since allocations from the symbolizer are done with the system allocator (at least in TSan, interceptors are skipped when inside the symbolizer), we will crash when we try to deallocate later using the sanitizer allocator again.
To fix this, let's just not call dlsym from the demangler, and call it during initialization. The dlsym function calls malloc, so it needs to be only used after our allocator is initialized. Adding a Symbolizer::LateInitialize call that is only invoked after all other initializations.
Differential Revision: http://reviews.llvm.org/D20015
llvm-svn: 269291
In recovery mode, when ASan detects stack overflow (say, when infinite recursion detected),
it tries to continue program execution and hangs on repetitive error reports. There isn't any
sense to do it, we can just bail out on stack overflow error, because the program would crash soon anyway.
Differential Revision: http://reviews.llvm.org/D19958
llvm-svn: 268713
Bruno Cardoso Lopes