| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 201413
|
|
|
|
|
|
| |
Android headers define clone() as a 4-argument function without ellipsis.
llvm-svn: 201331
|
|
|
|
| |
llvm-svn: 201304
|
|
|
|
|
|
| |
garbage colection to work with asan's fake stack
llvm-svn: 200908
|
|
|
|
| |
llvm-svn: 200686
|
|
|
|
|
|
| |
-fno-function-sections is broken in Clang.
llvm-svn: 200684
|
|
|
|
|
|
|
| |
It breaks when a binary is linked with --gc-sections: parts of sanitizer
interface get thrown away and inaccessible from dlopen-ed libs.
llvm-svn: 200683
|
|
|
|
|
|
|
|
| |
code stripping on Linux.
See https://code.google.com/p/address-sanitizer/issues/detail?id=260 for more info.
llvm-svn: 200553
|
|
|
|
|
|
| |
https://code.google.com/p/address-sanitizer/issues/detail?id=259
llvm-svn: 200468
|
|
|
|
|
|
| |
__attribute__((tls_model(initial-exec))))
llvm-svn: 200463
|
|
|
|
|
|
| |
causes trouble; few more debugging
llvm-svn: 200462
|
|
|
|
|
|
| |
interesting, actual usage will come later. See https://groups.google.com/forum/#!topic/address-sanitizer/BfwYD8HMxTM for background
llvm-svn: 200384
|
|
|
|
| |
llvm-svn: 199370
|
|
|
|
| |
llvm-svn: 197901
|
|
|
|
| |
llvm-svn: 197670
|
|
|
|
| |
llvm-svn: 196569
|
|
|
|
| |
llvm-svn: 196491
|
|
|
|
|
|
| |
in cmake build (PR18144). This is a quick fix. Will need to fix the configure/make build properly
llvm-svn: 196490
|
|
|
|
| |
llvm-svn: 196374
|
|
|
|
|
|
| |
stack buffer overflows in another test
llvm-svn: 196373
|
|
|
|
| |
llvm-svn: 195959
|
|
|
|
| |
llvm-svn: 195958
|
|
|
|
|
|
|
|
| |
I still don't know what is causing our bootstrapped LTO buildbots to fail,
but llvm r194701 seems to be OK and I can't imagine that these changes could
cause the problem.
llvm-svn: 194790
|
|
|
|
|
|
|
|
|
| |
Apple's bootstrapped LTO builds have been failing, and these changes (along
with llvm 194701) are the only things on the blamelist. I will either reapply
these changes or help debug the problem, depending on whether this fixes the
buildbots.
llvm-svn: 194779
|
|
|
|
| |
llvm-svn: 194702
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
(https://code.google.com/p/address-sanitizer/issues/detail?id=233)
llvm-svn: 194572
|
|
|
|
|
|
| |
check_initialization_order
llvm-svn: 194125
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D1984
llvm-svn: 193449
|
|
|
|
|
|
| |
predictable on Mac
llvm-svn: 192677
|
|
|
|
|
|
| |
comes with asan by default)
llvm-svn: 191204
|
|
|
|
|
|
| |
and enable it explicitly in tests. This is done in preparation to enabling the -fsanitize=use-after-return compile-time flag by default when -fsanitize=address is present.
llvm-svn: 191184
|
|
|
|
| |
llvm-svn: 190592
|
|
|
|
|
|
| |
at compile time instead of at run-time. compiler-rt part
llvm-svn: 190406
|
|
|
|
| |
llvm-svn: 190274
|
|
|
|
| |
llvm-svn: 190157
|
|
|
|
|
|
| |
signal-safe
llvm-svn: 189943
|
|
|
|
| |
llvm-svn: 187877
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, the reason I came here: I forgot to look at readdir64_r which had
the exact same bug as readdir_r. However, upon applying the same
quick-fix and testing it I discovered that it still didn't work at all.
As a consequence, I spent some time studying the code and thinking about
it and fixed several other problems.
Second, the code was checking for a null entry and result pointer, but
there is no indication that null pointers are viable here. Certainly,
the spec makes it extremely clear that there is no non-error case where
the implementation of readdir_r fails to dereference the 'result'
pointer and store NULL to it. Thus, our checking for a non-null 'result'
pointer before reflecting that write in the instrumentation was
trivially dead. Remove it.
Third, the interceptor was marking the write to the actual dirent struct
by looking at the entry pointer, but nothing in the spec requires that
the dirent struct written is actually written into the entry structure
provided. A threadlocal buffer would be just as conforming, and the spec
goes out of its way to say the pointer to the *actual* result dirent
struct is stored into *result, so *that* is where the interceptor should
reflect a write occuring. This also obviates the need to even consider
whether the 'entry' parameter is null.
Fourth, I got to the bottom of why nothing at all worked in readdir64_r
-- the interceptor structure for dirent64 was completely wrong in that
it was the same as dirent. I fixed this struct to be correct (64-bit
inode and 64-bit offset! just a 64-bit offset isn't enough!) and added
several missing tests for the size and layout of this struct.
llvm-svn: 186109
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directory stream, the entry is not written to, instead *result is set to
NULL and the entry is not written to at all.
I'm still somewhat suspicious of the correct instrumention here --
I feel like it should be marking the written range as the pointer in
*result and the length (*result)->d_reclen in case the implementation
decides not to use the passed-in entry (if that's even allowed).
Finally, the definition of 'struct dirent' analog used in the
interceptor is wrong in 32-bit mode with _FILE_OFFSET_BITS=64 as it hard
codes the use of a pointer-sized offset.
I've added a somewhat goofy test for the bug I fixed via ASan --
suggestions on how to better test the interceptor logic itself welcome.
llvm-svn: 185998
|
|
|
|
| |
llvm-svn: 185315
|
|
|
|
|
|
| |
instead of python script
llvm-svn: 185163
|
|
|
|
| |
llvm-svn: 185142
|
|
|
|
| |
llvm-svn: 184639
|
|
|
|
| |
llvm-svn: 184541
|
|
|
|
|
|
| |
64-bit mode. Clean up RUN-lines in tests.
llvm-svn: 183498
|
|
llvm-svn: 183395
|