llvm-libc is expected to be built with sanitizers and not use interceptors in
the long run. For now though, we have a hybrid process, where functions
implemented in llvm-libc are instrumented, and glibc fills and sanitizer
interceptors fill in the rest.
Current sanitizers have an invariant that the REAL(...) function called from
inside of an interceptor is uninstrumented. A lot of interceptors call strlen()
in order to figure out the size of the region to check/poison. Switch these
callsites over to the internal, unsanitized implementation.
Reviewed By: hctim, vitalybuka
Differential Revision: https://reviews.llvm.org/D108316
Previously, on GLibc systems, the interceptor was calling __compat_regexec
(regexec@GLIBC_2.2.5) insead of the newer __regexec (regexec@GLIBC_2.3.4).
The __compat_regexec strips the REG_STARTEND flag but does not report an
error if other flags are present. This can result in infinite loops for
programs that use REG_STARTEND to find all matches inside a buffer (since
ignoring REG_STARTEND means that the search always starts from the first
character).
The underlying issue is that GLibc's dlsym(RTLD_NEXT, ...) appears to
always return the oldest versioned symbol instead of the default. This
means it does not match the behaviour of dlsym(RTLD_DEFAULT, ...) or the
behaviour documented in the manpage.
It appears a similar issue was encountered with realpath and worked around
in 77ef78a0a5.
See also https://sourceware.org/bugzilla/show_bug.cgi?id=14932 and
https://sourceware.org/bugzilla/show_bug.cgi?id=1319.
Fixes https://github.com/google/sanitizers/issues/1371
Reviewed By: #sanitizers, vitalybuka, marxin
Differential Revision: https://reviews.llvm.org/D96348
Previously in ASan's `pthread_create` interceptor we would block in the
`pthread_create` interceptor waiting for the child thread to start.
Unfortunately this has bad performance characteristics because the OS
scheduler doesn't know the relationship between the parent and child
thread (i.e. the parent thread cannot make progress until the child
thread makes progress) and may make the wrong scheduling decision which
stalls progress.
It turns out that ASan didn't use to block in this interceptor but was
changed to do so to try to address
http://llvm.org/bugs/show_bug.cgi?id=21621/.
In that bug the problem being addressed was a LeakSanitizer false
positive. That bug concerns a heap object being passed
as `arg` to `pthread_create`. If:
* The calling thread loses a live reference to the object (e.g.
`pthread_create` finishes and the thread no longer has a live
reference to the object).
* Leak checking is triggered.
* The child thread has not yet started (once it starts it will have a
live reference).
then the heap object will incorrectly appear to be leaked.
This bug is covered by the `lsan/TestCases/leak_check_before_thread_started.cpp` test case.
In b029c5101f ASan was changed to block
in `pthread_create()` until the child thread starts so that `arg` is
kept alive for the purposes of leaking check.
While this change "works" its problematic due to the performance
problems it causes. The change is also completely unnecessary if leak
checking is disabled (via detect_leaks runtime option or
CAN_SANITIZE_LEAKS compile time config).
This patch does two things:
1. Takes a different approach to solving the leak false positive by
making LSan's leak checking mechanism treat the `arg` pointer of
created but not started threads as reachable. This is done by
implementing the `ForEachRegisteredThreadContextCb` callback for
ASan.
2. Removes the blocking behaviour in the ASan `pthread_create`
interceptor.
rdar://problem/63537240
Differential Revision: https://reviews.llvm.org/D95184
This fixes buildbot failures for https://reviews.llvm.org/rL372459.
(at least on PowerPC/Z )
The fix is generated by running clang-format on the error lines only.
llvm-svn: 372511
Summary:
strerror(3) on NetBSD uses internally TSD with a destructor that is never
fired for exit(3). It's correctly called for pthread_exit(3) scenarios.
This is a case when a leak on exit(3) is expected, unavoidable and harmless.
Reviewers: joerg, vitalybuka, dvyukov, mgorny
Reviewed By: vitalybuka
Subscribers: dmgreen, kristof.beyls, jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67337
llvm-svn: 372461
Summary:
The atexit(3) and __cxa_atexit() calls allocate internally memory and free on exit,
after executing all callback. This causes false positives as DoLeakCheck() is called
from the atexit handler. In the LSan/ASan tests there are strict checks triggering
false positives here.
Intercept all atexit(3) and __cxa_atexit() calls and disable LSan when calling the
real functions.
Stop tracing allocations in pthread_atfork(3) funtions, as there are performed
internal allocations that are not freed for the time of running StopTheWorld()
code. This avoids false-positives.
The same changes have to be replicated in the ASan and LSan runtime.
Non-NetBSD OSs are not tested and this code is restricted to NetBSD only.
Reviewers: dvyukov, joerg, mgorny, vitalybuka, eugenis
Reviewed By: vitalybuka
Subscribers: jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67331
llvm-svn: 372459
Kazuaki Ishizaki