to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
Move the corresponding tests to the common folder (as all of the
sanitizer allocators will support this feature soon) and add the checks
specific to aligned_alloc to ASan and LSan allocators.
Reviewers: vitalybuka
Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D47924
llvm-svn: 334316
Summary:
Currently many allocator specific errors (OOM, for example) are reported as
a text message and CHECK(0) termination, not stack, no details, not too
helpful nor informative. To improve the situation, ASan detailed errors were
defined and reported under the appropriate conditions.
Issue: https://github.com/google/sanitizers/issues/887
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44404
llvm-svn: 328722
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
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:
This is useful for inclusion in the Error* structures, to describe an
arbitrary address.
Remove the old struct since it's used only once. This removes one level of
indirection, and moves all *AddressDescription to be one of the recently
introduced structures.
This merges differential revisions: D24131 and D24132
Reviewers: kcc, eugenis, vitalybuka
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24131
llvm-svn: 281090
Summary:
Replacement for part of D23518
This deals with global variable addresses.
(This commit is written on top of D23605, but can be applied by itself)
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23607
llvm-svn: 278959
Summary:
Replacement for part of D23518
This deals with stack addresses.
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23605
llvm-svn: 278958
Summary:
Replacement for part of D23518
This deals with heap addresses, and renames DescribeHeapAddress.
Requires D23520, which moves code around to make it accessible in asan_describers.cc (and still accessible in asan_report.cc if needed).
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23569
llvm-svn: 278917
Summary:
Replacement for part of D23518
Code refactoring to allow us to move some more DescribeAddressIf* functions to work by getting the structured information, and then printing it.
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23520
llvm-svn: 278820
Summary:
Replacement for part of D23518
This is the first patch to start reifying information about errors. It deals only with reifying shadow address-related information.
It will allow us to generate structures with all the relevant information for a given error so a debugger can get to them or they can be included in a core dump.
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23519
llvm-svn: 278718
With -fsized-deallocation, new[] vs delete mismatch is reported as
new-delete-type-mismatch. This is technically true, but
alloc-dealloc-mismatch describes it better.
llvm-svn: 266246
mac_ignore_invalid_free was helpful when ASan runtime used to intercept
CFAllocator and sometimes corrupted its memory. This behavior had been long
gone, and the flag was unused.
This patch also deletes ReportMacCfReallocUnknown(), which was used by the
CFAllocator realloc() wrapper.
llvm-svn: 254722
introduce a BufferedStackTrace class, which owns this array.
Summary:
This change splits __sanitizer::StackTrace class into a lightweight
__sanitizer::StackTrace, which doesn't own array of PCs, and BufferedStackTrace,
which owns it. This would allow us to simplify the interface of StackDepot,
and eventually merge __sanitizer::StackTrace with __tsan::StackTrace.
Test Plan: regression test suite.
Reviewers: kcc, dvyukov
Reviewed By: dvyukov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5985
llvm-svn: 220635
Reviewed at http://reviews.llvm.org/D4527
Fixed a test case failure on 32-bit Linux, I did right shift on intptr_t, instead it should have been uintptr_t.
llvm-svn: 218538
Reviewed at http://reviews.llvm.org/D4527
This patch is part of an effort to implement a more generic debugging API, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074656.html, with first part reviewed at http://reviews.llvm.org/D4466. Now adding several new APIs: __asan_report_present, __asan_get_report_{pc,bp,sp,address,type,size,description}, __asan_locate_address. These return whether an asan report happened yet, the PC, BP, SP, address, access type (read/write), access size and bug description (e.g. "heap-use-after-free"), __asan_locate_address takes a pointer and tries to locate it, i.e. say whether it is a heap pointer, a global or a stack, or whether it's a pointer into the shadow memory. If global or stack, tries to also return the variable name, address and size. If heap, tries to return the chunk address and size. Generally these should serve as an alternative to "asan_describe_address", which only returns all the data in text form. Having an API to get these data could allow having debugging scripts/extensions that could show additional information about a variable/expression/pointer. Test cases in test/asan/TestCases/debug_locate.cc and test/asan/TestCasea/debug_report.cc.
llvm-svn: 218481
Introduce new public header <sanitizer/allocator_interface.h> and a set
of functions __sanitizer_get_ownership(), __sanitizer_malloc_hook() etc.
that will eventually replace their tool-specific equivalents
(__asan_get_ownership(), __msan_get_ownership() etc.). Tool-specific
functions are now deprecated and implemented as stubs redirecting
to __sanitizer_ versions (which are implemented differently in each tool).
Replace all uses of __xsan_ versions with __sanitizer_ versions in unit
and lit tests.
llvm-svn: 212469
Because of the way Bionic sets up signal stack frames, libc unwinder is unable
to step through it, resulting in broken SEGV stack traces.
Luckily, libcorkscrew.so on Android implements an unwinder that can start with
a signal context, thus sidestepping the issue.
llvm-svn: 201151
Invoke a fatal stack trace unwinder when ASan prints allocator-relevant
error reports (double-free, alloc-dealloc-mismatch, invalid-free).
Thus we'll be able to print complete stack trace even if allocation/free
stacks are not stored (malloc_context_size=0).
Based on the patch by Yuri Gribov!
llvm-svn: 194579
In case of partial right OOB, ASan was reporting
X is located 0 bytes to the right of [A, B)
where X was actually inside [A, B).
With this change, ASan will report B as the error address in such case.
llvm-svn: 174373
library.
These headers are intended to be available to user code when built with
AddressSanitizer (or one of the other sanitizer's in the future) to
interface with the runtime library. As such, they form stable external
C interfaces, and the headers shouldn't be located within the
implementation.
I've pulled them out into what seem like fairly obvious locations and
names, but I'm wide open to further bikeshedding of these names and
locations.
I've updated the code and the build system to cope with the new
locations, both CMake and Makefile. Please let me know if this breaks
anyone's build.
The eventual goal is to install these headers along side the Clang
builtin headers when we build the ASan runtime and install it. My
current thinking is to locate them at:
<prefix>/lib/clang/X.Y/include/sanitizer/common_interface_defs.h
<prefix>/lib/clang/X.Y/include/sanitizer/asan_interface.h
<prefix>/lib/clang/X.Y/include/sanitizer/...
But maybe others have different suggestions?
Fixing the style of the #include between these headers at least unblocks
experimentation with installing them as they now should work when
installed in these locations.
llvm-svn: 162822
Chandler Carruth