summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/asan
Commit message (Collapse)AuthorAgeFilesLines
...
* Enable builds of darwin lsan by defaultFrancis Ricci2017-04-062-5/+1
| | | | | | | | | | | | Summary: Testing and asan leak detection are disabled by default. Reviewers: kubamracek, kcc Subscribers: srhines, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D31307 llvm-svn: 299669
* [asan] Move AsanCheckDynamicRTPrereqs check under flagMaxim Ostapenko2017-03-312-1/+4
| | | | | | | | | | 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
* [asan] Implement "scribble" flags, which overwrite free'd memory with 0x55Kuba Mracek2017-03-303-0/+30
| | | | | | | | This patch implements "Malloc Scribble" in ASan via "max_free_fill_size" and "free_fill_byte" flags, which can be used to overwrite free()'d memory. We also match the behavior of MallocScribble and MallocPreScribble env vars on macOS (see https://developer.apple.com/library/content/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html), which is a helpful tool to detect use-after-free bugs that happen in non-instrumented code. Differential Revision: https://reviews.llvm.org/D30101 llvm-svn: 299085
* [asan] Support line numbers in StackVarDescrKuba Mracek2017-03-303-2/+14
| | | | | | | | 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
* Add allocator_frees_and_returns_null_on_realloc_zero=false flag for ↵Filipe Cabecinhas2017-03-292-2/+10
| | | | | | | | | | | | | | | | | | | compatibility with allocators which allow a realloc(p, 0) and don't free the pointer. 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
* [powerpc] deactivate ManyThreadsTest asan test on powerpc64Bill Seurer2017-03-271-1/+2
| | | | | | | | | | | | This test case occassionally hangs when run on powerpc. This is also a problem on AArch64 (see https://bugs.llvm.org/show_bug.cgi?id=24389). Reactivate this when the problem is fixed. This could also be related to the same problem as with the tests ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, and several others that do not run reliably on powerpc. llvm-svn: 298873
* Add strtok interceptor for ASAN for Windows.Alex Shlyapnikov2017-03-231-0/+1
| | | | | | | | | | | | Summary: Fixes test broken by D30384 Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D31312 llvm-svn: 298658
* Revert r298174, r298173, r298169, r298159.Evgeniy Stepanov2017-03-203-27/+0
| | | | | | | | | | | 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
* [asan] Fix dead stripping of globals on Linux (compiler-rt)Evgeniy Stepanov2017-03-173-0/+27
| | | | | | | | 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
* [asan] trying to fix the windows buildKostya Serebryany2017-03-151-2/+4
| | | | llvm-svn: 297918
* [asan] add one more argument to __sanitizer_print_memory_profile, remove a ↵Kostya Serebryany2017-03-151-7/+14
| | | | | | redundant weak definition. llvm-svn: 297914
* Fix -Wstring-conversion instanceReid Kleckner2017-03-151-1/+1
| | | | llvm-svn: 297879
* Some ASan bots (AArch64 at least) use SEGV for a unit test error instead of ↵Filipe Cabecinhas2017-03-141-1/+1
| | | | | | SIGBUS llvm-svn: 297728
* [asan] Split SIGSEGV / SIGBUS handling so we can handle only one of them and ↵Filipe Cabecinhas2017-03-131-1/+1
| | | | | | | | | | | | | | not the other. 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
* [sanitizer] Bail out with warning if user dlopens shared library with ↵Maxim Ostapenko2017-03-091-3/+5
| | | | | | | | | | | | RTLD_DEEPBIND flag People keep hitting on spurious failures in malloc/free routines when using sanitizers with shared libraries dlopened with RTLD_DEEPBIND (see https://github.com/google/sanitizers/issues/611 for details). Let's check for this flag and bail out with warning message instead of failing in random places. Differential Revision: https://reviews.llvm.org/D30504 llvm-svn: 297370
* Restrict usage of MemoryMappingLayout to platforms which support itFilipe Cabecinhas2017-03-011-0/+2
| | | | llvm-svn: 296657
* Reapply r296419: [asan] Print a "PC is at a non-executable memory region" ↵Filipe Cabecinhas2017-03-011-0/+11
| | | | | | | | | | | | | | message if that's the case 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
* Revert r296419 since the strings appear to need some tweaking.Filipe Cabecinhas2017-02-281-11/+0
| | | | llvm-svn: 296428
* [asan] Print a "PC is at a non-executable memory region" message if that's ↵Filipe Cabecinhas2017-02-281-0/+11
| | | | | | | | | | | | | | the case 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
* [compiler-rt][asan] Add support for desallocation of unhandled pointersEtienne Bergeron2017-02-215-0/+19
| | | | | | | | | | | | | | 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
* [compiler-rt][asan|win] Fix ASAN exception handler missing importEtienne Bergeron2017-02-151-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: This patch is adding a missing ASAN API redirection from an instrumented DLL. The bug was introduced here: https://reviews.llvm.org/D29463 This is causing this chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=692580 Reviewers: rnk Reviewed By: rnk Subscribers: kubamracek, dberris, llvm-commits, chrisha, thakis Differential Revision: https://reviews.llvm.org/D30001 llvm-svn: 295232
* Add cmake build support for lsan on OS XFrancis Ricci2017-02-141-0/+6
| | | | | | | | | | | | | | | | | | | | Summary: Adds a new cmake flag 'COMPILER_RT_ENABLE_LSAN_OSX', which enables lsan compilation and is turned off by default. Patches to fix build errors when this flag is enabled will be uploaded soon. This is part of an effort to port LSan to OS X, but LSan on OS X does not currently work or pass tests currently. Reviewers: kubamracek, kcc, glider, alekseyshl Reviewed By: kubamracek Subscribers: danalbert, srhines, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29783 llvm-svn: 295012
* build: repair cross-compilation with clangSaleem Abdulrasool2017-02-081-3/+3
| | | | | | | | | | | | When building for Windows, we would check if we were using MSVC rather than WIN32. This resulted in needed targets not being defined by sanitizer_common. Fix the conditional. When registering the objects libraries for ASAN, we would multiply register for all targets as we were creating them inside a loop over all architectures. Only define the target per architecture. llvm-svn: 294510
* asan_symbolize.py: [Py3] Get rid of "print" statement. Use print() or ↵NAKAMURA Takumi2017-02-081-11/+11
| | | | | | | | write() instead. Differential Revision: https://reviews.llvm.org/D27404 llvm-svn: 294450
* asan_symbolize.py: [Py3] Use text mode with universal_newlines=True for Popen.NAKAMURA Takumi2017-02-071-2/+6
| | | | | | | | | With universal_newlines, readline() stalls to fill the buffer. Therefore, let the pipe unbuffered. This is part of https://reviews.llvm.org/D27404 FIXME: Use Popen.communicate() llvm-svn: 294303
* [asan] Remove `using std::vector` and `using std::map`Alexander Kornienko2017-02-064-5/+4
| | | | | | Looks like these are not needed anymore. llvm-svn: 294200
* [sanitizer] Use interception to access to strong definitions in the executable.Marcos Pividori2017-02-022-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Windows, when sanitizers are implemented as a shared library (DLL), users can redefine and export a new definition for weak functions, in the main executable, for example: extern "C" __declspec(dllexport) void __sanitizer_cov_trace_pc_guard(u32* guard) { // Different implementation provided by the client. } However, other dlls, will continue using the default implementation imported from the sanitizer dll. This is different in linux, where all the shared libraries will consider the strong definition. With the implementation in this diff, when the dll is initialized, it will check if the main executable exports the definition for some weak function (for example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will override the function in the dll with that pointer. So, all the dlls with instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll, will be using the function provided by the main executable. In other words, when the main executable exports a strong definition for a weak function, we ensure all the dlls use that implementation instead of the default weak implementation. The behavior is similar to linux. Now, every user that want to override a weak function, only has to define and export it. The same for Linux and Windows, and it will work fine. So, there is no difference on the user's side. All the sanitizers will include a file sanitizer_win_weak_interception.cc that register sanitizer's weak functions to be intercepted in the binary section WEAK When the sanitizer dll is initialized, it will execute weak_intercept_init() which will consider all the CB registered in the section WEAK. So, for all the weak functions registered, we will check if a strong definition is provided in the main executable. All the files sanitizer_win_weak_interception.cc are independent, so we do not need to include a specific list of sanitizers. Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it will consider all the weak functions from asan, ubsan and sanitizer coverage. After this diff, sanitizer coverage is fixed for MD on Windows. In particular libFuzzer can provide custom implementation for all sanitizer coverage's weak functions, and they will be considered by asan dll. Differential Revision: https://reviews.llvm.org/D29168 llvm-svn: 293958
* [asan] Intercept SetUnhandledExceptionFilter.Marcos Pividori2017-02-021-24/+42
| | | | | | | | | | | | | | | | 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
* [sanitizer] Move DescribeSignalOrException to sanitizer_common.Marcos Pividori2017-02-024-44/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D29459 llvm-svn: 293956
* [sanitizer] Move exception code to sanitizer_common.Marcos Pividori2017-02-021-28/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D29458 llvm-svn: 293955
* [asan] Properly handle exceptions.Marcos Pividori2017-02-021-10/+32
| | | | | | Differential Revision: https://reviews.llvm.org/D29457 llvm-svn: 293954
* [sanitizer] Add dynamic_runtime_thunk for different sanitizers.Marcos Pividori2017-02-022-8/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Windows, when the sanitizer is implemented as a shared library (DLL), we need an auxiliary static library dynamic_runtime_thunk that will be linked to the main executable and dlls. In the sanitizer DLL, we are exposing weak functions with WIN_WEAK_EXPORT_DEF(), which exports the default implementation with __dll suffix. For example: for sanitizer coverage, the default implementation of __sanitizer_cov_trace_cmp is exported as: __sanitizer_cov_trace_cmp__dll. In the dynamic_runtime_thunk static library, we include weak aliases to the imported implementation from the dll, using the macro WIN_WEAK_IMPORT_DEF(). By default, all users's programs that include calls to weak functions like __sanitizer_cov_trace_cmp, will be redirected to the implementation in the dll, when linking to dynamic_runtime_thunk. After this diff, we are able to compile code with sanitizer coverage instrumentation on Windows. When the instrumented object files are linked with clang-rt_asan_dynamic_runtime_thunk-arch.lib all the weak symbols will be resolved to the implementation imported from asan dll. All the files sanitizer_dynamic_runtime_thunk.cc are independent, so we do not need to include a specific list of sanitizers. Now, we compile: [asan|ubsan|sanitizer_coverage]_win_dynamic_runtime_thunk.cc and sanitizer_win_dynamic_runtime_thunk.cc to generate asan_dynamic_runtime_thunk.lib, because we include asan, ubsan and sanitizer coverage in the address sanitizer library. Differential Revision: https://reviews.llvm.org/D29158 llvm-svn: 293953
* [sanitizer] Intercept weak functions in dll_thunks.Marcos Pividori2017-02-021-1/+1
| | | | | | | | | | | | | | In this diff, I update current implementation of the interception in dll_thunks to consider the special case of weak functions. First we check if the client has redefined the function in the main executable (for example: __sanitizer_cov_trace_pc_guard). It we can't find it, then we look for the default implementation (__sanitizer_cov_trace_pc_guard__dll). The default implementation is always available because the static runtime is linked to the main executable. Differential Revision: https://reviews.llvm.org/D29155 llvm-svn: 293952
* [sanitizer] Split dll_thunks into different sanitizers.Marcos Pividori2017-02-023-408/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the sanitizer is implemented as a static library and is included in the main executable, we need an auxiliary static library dll_thunk that will be linked to the dlls that have instrumentation, so they can refer to the runtime in the main executable. Basically, it uses interception to get a pointer the function in the main executable and override its function with that pointer. Before this diff, all of the implementation for dll_thunks was included in asan. In this diff I split it into different sanitizers, so we can use other sanitizers regardless of whether we include asan or not. All the sanitizers include a file sanitizer_win_dll_thunk.cc that register functions to be intercepted in the binary section: DLLTH When the dll including dll_thunk is initialized, it will execute __dll_thunk_init() implemented in: sanitizer_common/sanitizer_win_dll_thunk.cc, which will consider all the CB registered in the section DLLTH. So, all the functions registered will be intercepted, and redirected to the implementation in the main executable. All the files "sanitizer_win_dll_thunk.cc" are independent, so we don't need to include a specific list of sanitizers. Now, we compile: asan_win_dll_thunk.cc ubsan_win_dll_thunk.cc, sanitizer_coverage_win_dll_thunk.cc and sanitizer_win_dll_thunk.cc, to generate asan_dll_thunk, because we include asan, ubsan and sanitizer coverage in the address sanitizer library. Differential Revision: https://reviews.llvm.org/D29154 llvm-svn: 293951
* [tsan] Properly describe GCD worker threads in reportsKuba Mracek2017-02-022-2/+4
| | | | | | | | When dealing with GCD worker threads, TSan currently prints weird things like "created by thread T-1" and "[failed to restore the stack]" in reports. This patch avoids that and instead prints "Thread T3 (...) is a GCD worker thread". Differential Revision: https://reviews.llvm.org/D29103 llvm-svn: 293882
* [sanitizer] Add list of symbols exported in sanitizers' interface.Marcos Pividori2017-01-312-3/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [sanitizer] Define as weak, functions that are declared as weak.Marcos Pividori2017-01-311-2/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D29228 llvm-svn: 293681
* [asan] Export __sancov_* symbols symbols.Marcos Pividori2017-01-311-0/+1
| | | | | | | | Add __sancov_* symbols to the export list. Differential Revision: https://reviews.llvm.org/D29317 llvm-svn: 293680
* Recommit: Stop intercepting some malloc-related functions on FreeBSD andDimitry Andric2017-01-302-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [asan] Fix tests for exported interfaces.Marcos Pividori2017-01-291-1/+1
| | | | | | | | 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
* [asan] Add missing declaration in the internal interfaceMarcos Pividori2017-01-291-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D29230 llvm-svn: 293423
* General definition for weak functionsMarcos Pividori2017-01-296-39/+11
| | | | | | | | | | | | | | | | | | 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
* Revert "Stop intercepting some malloc-related functions on FreeBSD and macOS"Evgeniy Stepanov2017-01-271-13/+5
| | | | | | | | 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
* Stop intercepting some malloc-related functions on FreeBSD and macOSDimitry Andric2017-01-271-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [powerpc] deactivate ThreadedOneSizeMallocStressTest asan test on powerpc64Bill Seurer2017-01-251-0/+5
| | | | | | | This has not reliably worked on powerpc since r279664. Re-enable this once the problem is tracked down and fixed. llvm-svn: 293066
* [powerpc] deactivate ThreadedMallocStressTest asan test on powerpc64Bill Seurer2017-01-241-0/+4
| | | | | | | This has not reliably worked on powerpc since r279664. Re-enable this once the problem is tracked down and fixed. llvm-svn: 292945
* [sanitizer] [asan] Use macros to simplify weak aliases on Windows.Marcos Pividori2017-01-204-60/+12
| | | | | | | | | This patch adds some useful macros for dealing with pragma directives on Windows. Also, I add appropriate documentation for future users. Differential Revision: https://reviews.llvm.org/D28525 llvm-svn: 292650
* ASAN activate/deactive controls thread_local_quarantine_size_kb option.Alex Shlyapnikov2017-01-123-6/+14
| | | | | | | | | | | | | | | 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
* Revert "[sancov] moving sancov rt to sancov/ directory"Mike Aizatsky2017-01-122-5/+0
| | | | | | | | This reverts commit https://reviews.llvm.org/rL291734 Reason: mac breakage http://lab.llvm.org:8080/green//job/clang-stage1-configure-RA_build/28798/consoleFull#1657087648e9a0fee5-ebcc-4238-a641-c5aa112c323e llvm-svn: 291736
* [sancov] moving sancov rt to sancov/ directoryMike Aizatsky2017-01-122-0/+5
| | | | | | | | Subscribers: kubabrecka, mgorny Differential Revision: https://reviews.llvm.org/D28541 llvm-svn: 291734
OpenPOWER on IntegriCloud