This way downstream tools that read sanitizer output can differentiate between OOM errors
reported by sanitizers from other sanitizer errors.
Changes:
- Introduce ErrorIsOOM for checking if a platform-specific error code from an "mmap" is an OOM err.
- Add ReportOOMError which just prepends this error message to the start of a Report call.
- Replace some Reports for OOMs with calls to ReportOOMError.
- Update necessary tests.
Differential Revision: https://reviews.llvm.org/D127161
If sanitizer cannot determine name of the module it
will use "<unknown module>". Then it can be suppressed
if needed.
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D121674
See post-commit discussion on https://reviews.llvm.org/D120305.
This change breaks the clang-ppc64le-rhel buildbot, though
there is suspicion that it's an issue with the bot. The change
also had a larger than expected impact on compile-time and
code-size.
This reverts commit 3c4ed02698
and some followup changes.
We (Linaro) still have the occasional failure here due
to high load on a shared buildbot machine.
We are looking into general soloutions but perhaps this
will help in the meantime.
On Ubuntu Focal x13 is used by something in the process of calling
sched_yield. Causing the test to fail depending on when the thread
is stopped.
Adding x14 works around this and the test passes consistently.
Not switching to only x14 because that could make other platforms
fail. With both we'll always find at least one and even if both
values are present we'll only get one report.
Reviewed By: oontvoo, vitalybuka
Differential Revision: https://reviews.llvm.org/D110931
We have been seeing this test fail intermittently on our
2 stage AArch64 bot.
As far back as https://lab.llvm.org/buildbot/#/builders/53/builds/2694
Likely due to a lack of resources at certain times on the
shared machine. Up the time limit to give us some more room.
(this limit only applies to the watchdog thread, so if the
test passes then it won't take 20s)
This test from @MaskRay comment on D69428. The patch is looking to
break this behavior. If we go with D69428 I hope we will have some
workaround for this test or include explicit test update into the patch.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D100906
... so that FreeBSD specific GetTls/glibc specific pthread_self code can be
removed. This also helps FreeBSD arm64/powerpc64 which don't have GetTls
implementation yet.
GetTls is the range of
* thread control block and optional TLS_PRE_TCB_SIZE
* static TLS blocks plus static TLS surplus
On glibc, lsan requires the range to include
`pthread::{specific_1stblock,specific}` so that allocations only referenced by
`pthread_setspecific` can be scanned.
This patch uses `dl_iterate_phdr` to collect TLS blocks. Find the one
with `dlpi_tls_modid==1` as one of the initially loaded module, then find
consecutive ranges. The boundaries give us addr and size.
This allows us to drop the glibc internal `_dl_get_tls_static_info` and
`InitTlsSize`. However, huge glibc x86-64 binaries with numerous shared objects
may observe time complexity penalty, so exclude them for now. Use the simplified
method with non-Android Linux for now, but in theory this can be used with *BSD
and potentially other ELF OSes.
This removal of RISC-V `__builtin_thread_pointer` makes the code compilable with
more compiler versions (added in Clang in 2020-03, added in GCC in 2020-07).
This simplification enables D99566 for TLS Variant I architectures.
Note: as of musl 1.2.2 and FreeBSD 12.2, dlpi_tls_data returned by
dl_iterate_phdr is not desired: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774
This can be worked around by using `__tls_get_addr({modid,0})` instead
of `dlpi_tls_data`. The workaround can be shared with the workaround for glibc<2.25.
This fixes some tests on Alpine Linux x86-64 (musl)
```
test/lsan/Linux/cleanup_in_tsd_destructor.c
test/lsan/Linux/fork.cpp
test/lsan/Linux/fork_threaded.cpp
test/lsan/Linux/use_tls_static.cpp
test/lsan/many_tls_keys_thread.cpp
test/msan/tls_reuse.cpp
```
and `test/lsan/TestCases/many_tls_keys_pthread.cpp` on glibc aarch64.
The number of sanitizer test failures does not change on FreeBSD/amd64 12.2.
Differential Revision: https://reviews.llvm.org/D98926
These tests were added in:
1daa48f00559e422c90b
malloc_zero.c and realloc_too_big.c fail when only
leak sanitizer is enabled.
http://lab.llvm.org:8011/#/builders/59/builds/1635
(also in an armv8 32 bit build)
(I would XFAIL them but the same test is run with
address and leak sanitizer enabled and that one does
pass)
With D98926, many_tls_keys_pthread.cpp appears to be working.
On glibc 2.30-0ubuntu2, swapcontext.cpp and Linux/fork_and_leak.cpp work fine
but they strangely fail on clang-cmake-aarch64-full
(https://lab.llvm.org/buildbot/#/builders/7/builds/2240).
Disable them for now.
Note: check-lsan was recently enabled on AArch64 in D98985. A test takes
10+ seconds. We should figure out the bottleneck.
`check-lsan` passed on an aarch64-*-linux machine.
Unsupport `many_tls_keys_pthread.cpp` for now: it requires GetTls to include
`specific_1stblock` and `specific` in `struct pthread`.
Differential Revision: https://reviews.llvm.org/D98985
The recent suffix-log-path_test.c checks for a full stacktrace and
since on some arm-linux-gnu configuration the slow unwinder is used
on default (when the compiler emits thumb code as default), it
requires -funwind-tables on tests.
It also seems to fix the issues disable by d025df3c1d.
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D96337
Some tests are broken at API level 30 on AOSP-master devices. When we
change the buildbuit to API level 30, the following tests get enabled.
They're currently broken due to various issues, and so fix up those
issues.
Reviewed By: oontvoo, eugenis
Differential Revision: https://reviews.llvm.org/D94100
This makes suppression list to work similar to __lsan_ignore_object.
Existing behavior was inconsistent and very inconvenient for complex
data structures.
Example:
struct B;
struct A { B* ptr; };
A* t = makeA();
t->ptr = makeB();
Before the patch: if makeA suppressed by suppression file, lsan will
still report the makeB() leak, so we need two suppressions.
After the patch: a single makeA suppression is enough (the same as a
single __lsan_ignore_object(t)).
Differential Revision: https://reviews.llvm.org/D93884
The tests do not report the expected leak when issued with use_stack
or use_tls option equal to 0 on arm-linux-gnueabihf (ubuntu 18.04,
glibc 2.27).
This issue is being tracked by https://bugs.llvm.org/show_bug.cgi?id=48052
This commit adds an interceptor for the pthread_detach function,
calling into ThreadRegistry::DetachThread, allowing for thread contexts
to be reused.
Without this change, programs may fail when they create more than 8K
threads.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=47389
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D88184
X86 can use xmm registers for pointers operations. e.g. for std::swap.
I don't know yet if it's possible on other platforms.
NT_X86_XSTATE includes all registers from NT_FPREGSET so
the latter used only if the former is not available. I am not sure how
reasonable to expect that but LLD has such fallback in
NativeRegisterContextLinux_x86_64::ReadFPR.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87754
Leonard Chan