| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
Stop using the Linux solution with pthread_key_create(3).
This approach does not work on NetBSD, because calling
the thread destructor is not the latest operation on a POSIX
thread entity.
Detect _lwp_exit(2) call as it is really the latest operation
called from a detaching POSIX thread.
The pthread_key_create(3) solution also cannot be used
in early libc/libpthread initialization on NetBSD as the
system libraries are not bootstrapped enough.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, dvyukov
Reviewed By: dvyukov
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40457
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@318994 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Part of https://github.com/google/sanitizers/issues/637
Reviewers: eugenis, alekseyshl
Subscribers: llvm-commits, dberris, kubamracek, krytarowski
Differential Revision: https://reviews.llvm.org/D37608
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
NetBSD is a modern POSIX-like UNIX-like Operating System derived from 4.4BSD/386BSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, dvyukov
Reviewed By: kcc
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D37307
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312184 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Based on r282019.
Reviewers: kcc, jakubjelinek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36757
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@311030 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Calling exit() from an atexit handler is undefined behavior.
On Linux, it's unavoidable, since we cannot intercept exit (_exit isn't called
if a user program uses return instead of exit()), and I haven't
seen it cause issues regardless.
However, on Darwin, I have a fairly complex internal test that hangs roughly
once in every 300 runs after leak reporting finishes, which is resolved with
this patch, and is presumably due to the undefined behavior (since the Die() is
the only thing that happens after the end of leak reporting).
In addition, this is the way TSan works as well, where an atexit handler+Die()
is used on Linux, and an _exit() interceptor is used on Darwin. I'm not sure if it's
intentionally structured that way in TSan, since TSan sets up the atexit handler and the
_exit() interceptor on both platforms, but I have observed that on Darwin, only the
_exit() interceptor is used, and on Linux the atexit handler is used.
There is some additional related discussion here: https://reviews.llvm.org/D35085
Reviewers: alekseyshl, kubamracek
Subscribers: eugenis, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D35513
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@308353 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
An attempt to reland D34786 (which caused bot failres on Mac), now with
properly intercepted operators new() and delete().
LSan allocator used to always return nullptr on too big allocation requests
(the definition of "too big" depends on platform and bitness), now it
follows policy configured by allocator_may_return_null flag
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34845
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306845 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306748 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r306624.
The committed test failed on various bots (e.g. on green dragon).
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306644 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
LSan allocator used to always return nullptr on too big allocation requests
(the definition of "too big" depends on platform and bitness), now it
follows policy configured by allocator_may_return_null flag.
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34786
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306604 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@304735 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It seems that on MAC allocator already locks on fork thus adding another ForceLock
in fork interceptor will cause a deadlock.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@304297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@304285 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch addresses https://github.com/google/sanitizers/issues/804.
Users can use mcheck and mprobe functions to verify heap state so we should intercept them to avoid breakage of valid code.
Differential Revision: https://reviews.llvm.org/D32589
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Lsan was using PTHREAD_CREATE_JOINABLE/PTHREAD_CREATE_DETACHED
as truthy values, which works on Linux, where the values are 0 and 1,
but this fails on OS X, where the values are 1 and 2.
Set PTHREAD_CREATE_DETACHED to the correct value for a given system.
Reviewers: kcc, glider, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31883
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300221 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Mimicks the existing tsan and asan implementations of
Darwin interception.
Reviewers: kubamracek, kcc, glider
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31889
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299979 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Fixes build issues when compiling lsan for darwin.
Reviewers: kubamracek, kcc, rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29785
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@294984 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The missed clang part was committed at https://reviews.llvm.org/rL293609 thus
we can reenable LSan for x86 Linux.
Differential Revision: https://reviews.llvm.org/D28609
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
macOS
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Also delete the non-functional `cfree` wrapper for Windows, to fix the
test cases on that platform.
Reviewers: emaste, kcc, rnk
Subscribers: timurrrr, eugenis, hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293536 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts r293337, which breaks tests on Windows:
malloc-no-intercept-499eb7.o : error LNK2019: unresolved external symbol _mallinfo referenced in function _main
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Reviewers: emaste, kcc
Subscribers: hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293337 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Breaks tests on i686/Linux due to missing clang driver support:
error: unsupported option '-fsanitize=leak' for target 'i386-unknown-linux-gnu'
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@292844 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
People keep asking LSan to be available on 32 bit targets (e.g. https://github.com/google/sanitizers/issues/403)
despite the fact that false negative ratio might be huge (up to 85%). This happens for big real world applications
that may contain random binary data (e.g. browser), but for smaller apps situation is not so terrible and LSan still might be useful.
This patch adds initial support for x86 Linux (disabled by default), ARM32 is in TODO list.
We used this patch (well, ported to GCC) on our 32 bit mobile emulators and it worked pretty fine
thus I'm posting it here to initiate further discussion.
Differential Revision: https://reviews.llvm.org/D28609
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@292775 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thread stack/TLS may be stored by libpthread for future reuse after
thread destruction, and the linked list it's stored in doesn't
even hold valid pointers to the objects, the latter are calculated
by obscure pointer arithmetic.
With this change applied, LSan test suite passes with
"use_ld_allocations" flag defaulted to "false". It still requires more
testing to check if the default can be switched.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@257975 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
We have a way to keep track of allocated DTLS segments: let's use it
in LSan. Although this code is fragile and relies on glibc
implementation details, in some cases it proves to be better than
existing way of tracking DTLS in LSan: marking as "reachable" all
memory chunks allocated directly by "ld".
The plan is to eventually get rid of the latter, once we are sure
it's safe to remove.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16164
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@257785 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@248966 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: I've copy/pasted the LLVM_NOEXCEPT definition macro goo from LLVM's Compiler.h. Is there somewhere I should put this in Compiler RT? Is there a useful header to define/share things like this?
Reviewers: samsonov
Differential Revision: http://reviews.llvm.org/D11780
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@244453 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
On Android L, TSD destructors run 8 times instead of 4.
Back to 4 times on the current master branch (as well as on K).
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@240992 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In the current scheme of things, the call to ThreadStart() in the child
thread is not synchronized with the parent thread. So, if a pointer is passed to
pthread_create, there may be a window of time during which this pointer will not
be discoverable by LSan. I.e. the pthread_create interceptor has already
returneed and thus the pointer is no longer on the parent stack, but we don't
yet know the location of the child stack. This has caused bogus leak reports
(see http://llvm.org/bugs/show_bug.cgi?id=21621/).
This patch makes the pthread_create interceptor wait until the child thread is
properly registered before returning.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@223419 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MSanDR is a dynamic instrumentation tool that can instrument the code
(prebuilt libraries and such) that could not be instrumented at compile time.
This code is unused (to the best of our knowledge) and unmaintained, and
starting to bit-rot.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@222232 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@216454 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@212322 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The interceptors had code that after macro expansion ended up looking like
extern "C" void memalign()
__attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
__attribute__((alias("memalign")));
That is,
* __interceptor_memalign is a function
* memalign is a weak alias to __interceptor_memalign
* __interceptor___libc_memalign is an alias to memalign
Both gcc and clang produce assembly that look like
__interceptor_memalign:
...
.weak memalign
memalign = __interceptor_memalign
.globl __interceptor___libc_memalign
__interceptor___libc_memalign = memalign
What it means in the end is that we have 3 symbols pointing to the
same position in the file, one of which is weak:
8: 0000000000000000 1 FUNC GLOBAL DEFAULT 1
__interceptor_memalign
9: 0000000000000000 1 FUNC WEAK DEFAULT 1 memalign
10: 0000000000000000 1 FUNC GLOBAL DEFAULT 1
__interceptor___libc_memalign
In particular, note that __interceptor___libc_memalign will always
point to __interceptor_memalign, even if we do link in a strong symbol
for memalign. In fact, the above code produces exactly the same binary
as
extern "C" void memalign()
__attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
__attribute__((alias("__interceptor_memalign")));
If nothing else, this patch makes it more obvious what is going on.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@204823 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
code so it seems it should have more generic name and moved to a common scope.
Renamed to AdjustStackSize.
Patch by Viktor Kutuzov.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@202011 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@201152 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operator delete[].
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@201016 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@197808 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No longer allow interceptors to be called during initialization, use the preinit
array (instead of initializing at the first call to an intercepted function) and
adopt the calloc() hack from ASan.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@195642 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
now it's available from common_flags()
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@192705 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@192533 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sanitizer_linux.h.
Add a test.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@192442 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Update the main thread's os_id on every pthread_create, and before
initiating leak checking. This ensures that we have the correct os_id even if we
have forked after Init().
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@185815 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@184849 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also remove unnecessary ifdefs.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@182571 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@182247 91177308-0d34-0410-b5e6-96231b3b80d8
|
