| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
We don't need to paste tokens here. String literal concatenation works
just fine here with MSVC and Clang.
llvm-svn: 307321
|
|
|
|
|
|
|
|
| |
This has been introduced in r304598 and fails for increased stack sizes.
Differential Revision: https://reviews.llvm.org/D34876
llvm-svn: 307127
|
|
|
|
| |
llvm-svn: 307124
|
|
|
|
| |
llvm-svn: 306746
|
|
|
|
|
|
|
| |
This missing export was causing allocator_returns_null.cc to fail on
Windows with a dynamic ASan runtime.
llvm-svn: 306707
|
|
|
|
|
|
|
|
|
|
|
| |
Do this by removing SANITIZER_INTERCEPT_WCSLEN and intercept wcslen
everywhere. Before this change, we were already intercepting wcslen on
Windows, but the interceptor was in asan, not sanitizer_common. After
this change, we stopped intercepting wcslen on Windows, which broke
asan_dll_thunk.c, which attempts to thunk to __asan_wcslen in the ASan
runtime.
llvm-svn: 306706
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Operator new interceptors behavior is now controlled by their nothrow
property as well as by allocator_may_return_null flag value:
- allocator_may_return_null=* + new() - die on allocation error
- allocator_may_return_null=0 + new(nothrow) - die on allocation error
- allocator_may_return_null=1 + new(nothrow) - return null
Ideally new() should throw std::bad_alloc exception, but that is not
trivial to achieve, hence TODO.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34731
llvm-svn: 306604
|
|
|
|
| |
llvm-svn: 306493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also move wcslen, wscnlen to common interceptors.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34656
llvm-svn: 306482
|
|
|
|
|
|
| |
Add ASan report to the "debug message" field in Android tombstones.
llvm-svn: 306184
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move cached allocator_may_return_null flag to sanitizer_allocator.cc and
provide API to consolidate and unify the behavior of all specific allocators.
Make all sanitizers using CombinedAllocator to follow
AllocatorReturnNullOrDieOnOOM() rules to behave the same way when OOM
happens.
When OOM happens, turn allocator_out_of_memory flag on regardless of
allocator_may_return_null flag value (it used to not to be set when
allocator_may_return_null == true).
release_to_os_interval_ms and rss_limit_exceeded will likely be moved to
sanitizer_allocator.cc too (later).
Reviewers: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34310
llvm-svn: 305858
|
|
|
|
|
|
|
| |
This fixes asan_device_setup failing to update an existing asan
installation.
llvm-svn: 305746
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is required for standalone LSan to work with libdispatch worker threads,
and is a slimmed down version of the functionality provided for ASan
in asan_mac.cc.
Re-commit of r305695 with use_stacks=0 to get around a racy lingering pointer.
Reviewers: alekseyshl, kubamracek, glider, kcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D34247
llvm-svn: 305732
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CombinedAllocator::Allocate cleared parameter is not used anywhere and
seem to be obsolete.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34289
llvm-svn: 305590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move the OOM decision based on RSS limits out of generic allocator to
ASan allocator, where it makes more sense at the moment.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34180
llvm-svn: 305342
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses PR 33206. There might be a situation when dynamic ASan runtime initializes later
than shared library which has malloc in static constructor (rtld doesn't provide an order of shared libs initialization).
In this case ASan hasn't yet initialized interceptors, but already intercepts malloc.
If malloc is too big to be handled by static local pool, ASan will die with error:
Sanitizer CHECK failed: lib/asan/asan_malloc_linux.cc:40 ((allocated_for_dlsym)) < ((kDlsymAllocPoolSize)) (1036, 1024)
Patch by Denis Khalikov.
Differential Revision: https://reviews.llvm.org/D33784
llvm-svn: 305058
|
|
|
|
|
|
|
|
|
|
|
| |
r304285 - [sanitizer] Avoid possible deadlock in child process after fork
r304297 - [sanitizer] Trying to fix MAC buildbots after r304285
These changes create deadlock when Tcl calls pthread_create from a
pthread_atfork child handler. More info in the original review at
https://reviews.llvm.org/D33325
llvm-svn: 304735
|
|
|
|
|
|
| |
async-signal-safe (during thread startup). beef-up the test to give it a chance to catch regressions. Also relax the lint to make C++11 more usable.
llvm-svn: 304598
|
|
|
|
| |
llvm-svn: 304504
|
|
|
|
| |
llvm-svn: 304503
|
|
|
|
|
|
|
|
| |
Recommit of r302781 with Vitaly Buka's fix for non zero terminated strings.
Differential Revision: https://reviews.llvm.org/D31457
llvm-svn: 304399
|
|
|
|
|
|
|
| |
It seems that on MAC allocator already locks on fork thus adding another ForceLock
in fork interceptor will cause a deadlock.
llvm-svn: 304297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses https://github.com/google/sanitizers/issues/774. When we
fork a multi-threaded process it's possible to deadlock if some thread acquired
StackDepot or allocator internal lock just before fork. In this case the lock
will never be released in child process causing deadlock on following memory alloc/dealloc
routine. While calling alloc/dealloc routines after multi-threaded fork is not allowed,
most of modern allocators (Glibc, tcmalloc, jemalloc) are actually fork safe. Let's do the same
for sanitizers except TSan that has complex locking rules.
Differential Revision: https://reviews.llvm.org/D33325
llvm-svn: 304285
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D33521 addressed a memory ordering issue in BlockingMutex, which seems
to be the cause of a flakiness of a few ASan tests on PowerPC.
Reviewers: eugenis
Subscribers: kubamracek, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33569
llvm-svn: 303995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
allow_user_segv_handler had confusing name did not allow to control behavior for
signals separately.
Reviewers: eugenis, alekseyshl, kcc
Subscribers: llvm-commits, dberris, kubamracek
Differential Revision: https://reviews.llvm.org/D33371
llvm-svn: 303941
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32443
llvm-svn: 303842
|
|
|
|
|
|
|
|
| |
Breaks sanitizer-x86_64-linux-fuzzer bot.
This reverts commit r303729.
llvm-svn: 303795
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32443
llvm-svn: 303729
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This flags is not covered by tests on Windows and looks like it's implemented
incorrectly. Switching its default breaks some tests.
Taking into account that related handle_segv flag is not supported on Windows
it's safer to remove it until we commit to support it.
Reviewers: eugenis, zturner, rnk
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33471
llvm-svn: 303728
|
|
|
|
|
|
|
|
| |
Failed libFuzzer tests on Windows.
This reverts commit r303476.
llvm-svn: 303481
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32443
llvm-svn: 303476
|
|
|
|
|
|
|
| |
The Msan unit tests are still broken and by this point, I think we
should start over.
llvm-svn: 303339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's used in asan_test.cc also on Windows, and my build was failing
with:
C:/src/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc:549:28: error: unknown type name 'jmp_buf'
NOINLINE void LongJmpFunc1(jmp_buf buf) {
^
C:/src/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc:569:10: error: unknown type name 'jmp_buf'
static jmp_buf buf;
^
I couldn't find what changed to make this not work anymore, but this should fix
it.
llvm-svn: 303273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With rL279771, SizeClassAllocator64 was changed to accept only one template
instead of 5, for the following reasons: "First, this will make the mangled
names shorter. Second, this will make adding more parameters simpler". This
patch mirrors that work for SizeClassAllocator32.
This is in preparation for introducing the randomization of chunks in the
32-bit SizeClassAllocator in a later patch.
Reviewers: kcc, alekseyshl, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33141
llvm-svn: 303071
|
|
|
|
|
|
|
|
|
| |
Fix undeclared __interceptor_malloc in esan_interceptors.cc
Fix undeclared strnlen on OSX
Differential Revision: https://reviews.llvm.org/D31457
llvm-svn: 302781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
glibc on Linux calls __longjmp_chk instead of longjmp (or _longjmp) when
_FORTIFY_SOURCE is defined. Ensure that an ASAN-instrumented program
intercepts this function when a system library calls it, otherwise the
stack might remain poisoned and result in CHECK failures and false
positives.
Fixes https://github.com/google/sanitizers/issues/721
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D32408
llvm-svn: 302152
|
|
|
|
| |
llvm-svn: 301909
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D31457
llvm-svn: 301904
|
|
|
|
| |
llvm-svn: 301837
|
|
|
|
|
|
|
| |
Third attempt. See the description of the corresponding commit in
LLVM for more details.
llvm-svn: 301588
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Refer to D32194 for the context.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32303
llvm-svn: 300886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On PowerPC and ARM (possibly, need to verify), couple tests involving
pthread_exit fail due to leaks detected by LSan. pthread_exit tries
to perform unwinding that leads to dlopen'ing libgcc_s.so. dlopen
mallocs "libgcc_s.so" string which confuses LSan, it fails to
realize that this allocation happens in dynamic linker and should
be ignored.
Symbolized leak report is required to define a suppression for this
known problem.
Reviewers: eugenis
Subscribers: aemerson, rengolin, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32194
Turn symbolization on for PPC and Thumb only to do not slow down other platforms.
llvm-svn: 300748
|
|
|
|
|
|
|
|
| |
We seem to assume that OS-provided thread IDs are either uptr or int, neither of which is true on Darwin. This introduces a tid_t type, which holds a OS-provided thread ID (gettid on Linux, pthread_threadid_np on Darwin, pthread_self on FreeBSD).
Differential Revision: https://reviews.llvm.org/D31774
llvm-svn: 300473
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: These leaks are detected by leak sanitizer for darwin.
Reviewers: glider, kubamracek, kcc, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31978
llvm-svn: 300080
|
|
|
|
|
|
| |
This patch reapplies r299923 with typo fixed in BLX macros.
llvm-svn: 299948
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FAILED: lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.arm.dir/sanitizer_linux.cc.o
lib/sanitizer_common/sanitizer_linux.cc:1340:24: error: invalid instruction
BLX(ip)
^
lib/sanitizer_common/sanitizer_linux.cc:1313:19: note: expanded from macro 'BLX'
# define BLX(R) "mov lr, pc; bx" #R "\n"
^
<inline asm>:6:13: note: instantiated into assembly here
mov lr, pc; bxip
^~~~
llvm-svn: 299943
|
|
|
|
|
|
|
|
| |
This patch enables LSan for arm Linux.
Differential Revision: https://reviews.llvm.org/D29586
llvm-svn: 299923
|
|
|
|
|
|
| |
This reverts r299698, which caused a big increase in object file size.
llvm-svn: 299881
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D31592
llvm-svn: 299867
|
|
|
|
|
|
| |
This is a re-land of r298173, r298169, r298159.
llvm-svn: 299698
|