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
Summary:
This (partially) implements the check mentioned at
http://kristerw.blogspot.co.uk/2016/04/dangling-pointers-and-undefined-behavior.html
(via John Regehr)
Quoting:
"That the behavior is undefined follows from C11 6.2.4 "Storage
durations of objects"
The lifetime of an object is the portion of program execution during
which storage is guaranteed to be reserved for it. An object exists, has
a constant address, and retains its last-stored value throughout its
lifetime. If an object is referred to outside of its lifetime, the
behavior is undefined. The value of a pointer becomes indeterminate when
the object it points to (or just past) reaches the end of its lifetime.
and 7.22.3 "Memory management functions" that says that free ends the
lifetime of objects
The lifetime of an allocated object extends from the allocation until
the deallocation.
"
We can probably implement this for stack variables too, but I think this
is a good start to see if there's interest in this check.
We can also hide this behind a flag, too.
Reviewers: samsonov, kcc, rsmith, regehr
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D19691
llvm-svn: 268097
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
ucrtbase.dll appears to be built with some kind of cross-module
inlining, because there are calls to imported Heap* routines sprinkled
throughout the code. This inlining defeats our attempts to hotpatch
malloc, _malloc_base, and related functions. Failing to intercept an
allocation or deallocation results in a crash when the program attempts
to deallocate or reallocate memory with the wrong allocator.
This change patches the IAT of ucrtbase.dll to replace the addresses of
the imported Heap* functions with implementations provided by ASan. We
don't globally intercept the win32 Heap* functions because they are
typically used by system DLLs that run before ASan initializes.
Eventually, we may want to intercept them, but for now I think this is
the minimal change that will keep ASan stable.
Reviewers: samsonov
Differential Revision: http://reviews.llvm.org/D18413
llvm-svn: 264327
- Trim spaces.
- Use nullptr in place of 0 for pointer variables.
- Use '!p' in place of 'p == 0' for null pointer checks.
- Add blank lines to separate function definitions.
- Add 'extern "C"' or 'namespace foo' comments after the appropriate
closing brackets
This is a continuation of work from 409b7b82. The focus here is on the
various sanitizers (not sanitizer_common, as before).
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D13225
llvm-svn: 248966
Now ASan deactivation doesn't modify common or ASan-specific runtime
flags. Flags stay constant after initialization, and "deactivation"
instead stashes initialized runtime state, and deactivates the
runtime. Activation then just restores the original state (possibly,
overriden by some activation flags provided in system property on
Android).
llvm-svn: 224614
Summary:
Reduce the dependency of allocator code on runtime flags. Instead,
pass a bunch of options that configure allocator behavior at
initialization or re-initialization. That would allow us to
cleaner modify allocator behavior during a program execution
when ASan is activated or de-activated.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: llvm-commits, eugenis
Differential Revision: http://reviews.llvm.org/D6711
llvm-svn: 224605
Introduce "Allocator" object, which contains all the bits and pieces
ASan allocation machinery actually use: allocator from sanitizer_common,
quarantine, fallback allocator and quarantine caches, fallback mutex.
This step is a preparation to adding more state to this object. We want
to reduce dependency of Allocator on commandline flags and be able to
"safely" modify its behavior (such as the size of the redzone) at
runtime.
llvm-svn: 224406
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
Etienne Bergeron