| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 194805
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
doesn't need them)
llvm-svn: 194685
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 194578
|
|
|
|
|
|
| |
(https://code.google.com/p/address-sanitizer/issues/detail?id=233)
llvm-svn: 194572
|
|
|
|
|
|
| |
The top stack frames for operator new and operator delete are different on Linux and Darwin.
llvm-svn: 194150
|
|
|
|
|
|
| |
check_initialization_order
llvm-svn: 194125
|
|
|
|
| |
llvm-svn: 194107
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D1984
llvm-svn: 193449
|
|
|
|
| |
llvm-svn: 192973
|
|
|
|
| |
llvm-svn: 192960
|
|
|
|
| |
llvm-svn: 192956
|
|
|
|
|
|
| |
valloc() on OSX.
llvm-svn: 192901
|
|
|
|
| |
llvm-svn: 192892
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a deadlock which happens in lsan
on a large memalign-allocated chunk that resides in lsan's root set.
Reviewers: samsonov, earthdok
Reviewed By: earthdok
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1957
llvm-svn: 192885
|
|
|
|
| |
llvm-svn: 192793
|
|
|
|
| |
llvm-svn: 192685
|
|
|
|
|
|
| |
predictable on Mac
llvm-svn: 192677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Out-of-bound access may touch not-yet allocated or already freed
and recycled from quarantine chunks. We should treat this situation as
a "free-range memory access" and avoid printing any data about that
irrelevant chunk (which may be inconsistent).
This should fix https://code.google.com/p/address-sanitizer/issues/detail?id=183
Reviewers: kcc
Reviewed By: kcc
CC: timurrrr, llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1893
llvm-svn: 192581
|
|
|
|
|
|
| |
FakeStack; don't crash when the fake stack is exhausted, move some code to .cc file
llvm-svn: 191510
|
|
|
|
|
|
| |
comes with asan by default)
llvm-svn: 191204
|
|
|
|
| |
llvm-svn: 191187
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
-Wl,-undefined,dynamic_lookup being passed to the linker.
llvm-svn: 191012
|
|
|
|
|
|
| |
output for fake stack
llvm-svn: 190932
|
|
|
|
|
|
| |
fixed android build of another test
llvm-svn: 190606
|
|
|
|
|
|
| |
sure this is a complete fix, will keep looking for harder cases.
llvm-svn: 190603
|
|
|
|
| |
llvm-svn: 190592
|
|
|
|
|
|
| |
at compile time instead of at run-time. compiler-rt part
llvm-svn: 190406
|
|
|
|
|
|
|
| |
strerror_r on OSX returns a positive error code when the errno value is
unknown. Buffer contents are initialized in any case.
llvm-svn: 190295
|
|
|
|
| |
llvm-svn: 190277
|
|
|
|
| |
llvm-svn: 190274
|
|
|
|
| |
llvm-svn: 190157
|
|
|
|
| |
llvm-svn: 190139
|
|
|
|
|
|
| |
the allocator_may_return_null flag)
llvm-svn: 190128
|
|
|
|
|
|
| |
(controlled by the allocator_may_return_null flag)
llvm-svn: 190127
|
|
|
|
|
|
| |
signal-safe
llvm-svn: 189943
|
|
|
|
|
|
| |
in UAR mode
llvm-svn: 189929
|
|
|
|
| |
llvm-svn: 189806
|
|
|
|
| |
llvm-svn: 189748
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change makes races between updates of thread-local stats and
merging all the thread-local stats together less harmful.
Reviewers: kcc
Reviewed By: kcc
CC: dvyukov, llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1572
llvm-svn: 189744
|
|
|
|
|
|
| |
stack-use-after-return.cc; add a test for UAR mode in asan_noinst_test
llvm-svn: 189457
|
|
|
|
|
| |
r187967: Disable inlining between sanitized and non-sanitized functions.
llvm-svn: 187971
|
|
|
|
| |
llvm-svn: 187881
|
|
|
|
| |
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
|