The malloc_zone.cpp test currently fails on Darwin hosts, in
SanitizerCommon
tests with lsan enabled.
Need to XFAIL this test to buy time to investigate this failure. Also
we're trying to bring the number of test failing on Darwin bots to 0, to
get clearer signal of any new failures.
rdar://145873843
Co-authored-by: Mariusz Borsa <m_borsa@apple.com>
Introduced a cmake option that is disabled by default that suppresses
searching via the PATH variable for a symbolizer. The option will be
enabled for downstream builds where the user will need to specify the
symbolizer path more explicitly, e.g., by using ASAN_SYMBOLIZER_PATH.
The functions are not relevant for most sanitizers and only required for
MSan to see which regions have been written to. This eliminates a link
dependency for all other sanitizers and fixes#59007: while `-lresolv`
had been added for the static runtime in 6dce56b2a308, it wasn't added
to the shared runtimes.
Instead of just moving the interceptors, we adapt them to MSan
conventions:
* We don't skip intercepting when `msan_init_is_running` is true, but
directly call ENSURE_MSAN_INITED() like most other interceptors. It
seems unlikely that these functions are called during initialization.
* We don't unpoison `errno`, because none of the functions is specified
to use it.
With PR #107223 and PR #107403, ASan testing can be enabled on SPARC.
This patch does so, 32-bit only on both Solaris and Linux. There is no
64-bit support even in GCC.
Apart from the obvious CMake changes, this patch includes a couple of
testcase adjustments necessary for SPARC:
- In `asan_oob_test.cpp`, the `OOB_int` subtest needs to be disabled: it
performs unaligned accesses that cannot work on a strict-alignment
target like SPARC.
- `asan_test.cpp` needs to disable subtests that depend on support for
`__builtin_setjmp` and `__builtin_longjmp`.
- `zero_page_pc.cpp` reports `0x5` as the faulting address on access to
`0x4`. I don't really know why, but it's consistent between Solaris and
Linux.
Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
The lit test has been failing on green dragon since it landed,
e.g. https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/2276/testReport/
This reverts commit a6ea0b0d2973d3d94f9ed7aac6db9ca722664774 and
follow-up commits ce72c76e9bd0bf74af614cae6a9f85cfd4720e95,
a280275cff497f96492d7c1094ba30309dbd3ad6, and
d705bd25eb9f11e100d3e79b65a80d446fd06f30.
`DlSymAllocator` allows early allocations, when
tsan is not yet initialized, e.g. from `dlsym`.
All other sanitizers with interceptors already use
`DlSymAllocator`.
Existing `in_symbolizer()` tsan logic is very similar.
However, we need to keep both as `DlSymAllocator`
does not support large allocations, needed for Symolizer.
Fixes asan, msan crash on check added in #108684.
The #108684 includes reproducer of the issue.
Change interface of `GetThreadStackAndTls` to
set `tls_begin` and `tls_end` at the same time.
There is possibility of
static_tls_begin is set and static_tls_end is not yet
The test reproduces the case.
Stack trace looks like this:
* `MsanThread::Init`
* `SetThreadStackAndTls`
* `GetThreadStackAndTls`
* `GetThreadStackTopAndBottom`
* `pthread_getattr_np`
* `realloc`
* `__sanitizer_malloc_hook`
* TLS access
* `___interceptor___tls_get_addr`
* `DTLS_on_tls_get_addr`
The issue is that `SetThreadStackAndTls` implementation
stores `tls_begin` before `GetThreadStackTopAndBottom`,
and `tls_end` after. So we have partially initialized
state in `DTLS_on_tls_get_addr`.
…p etc. on SPARC
When enabling ASan testing on SPARC as per PR #107405, two tests `FAIL`:
```
SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard-dso.cpp
SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard.cpp
```
The issue is the same in both cases:
```
WARNING: No coverage file for projects/compiler-rt/test/sanitizer_common/asan-sparc-SunOS/Output/sanitizer_coverage_trace_pc_guard.cpp.tmp
WARNING: No coverage file for sanitizer_coverage_trace_pc_guard.cpp.tmp.22766.sancov
ERROR: No valid coverage files given.
```
Checking the file with `sancov -print` reveals `Wrong magic:
4294967090`. There seems to be an endianess bug somewhere, since the
tests are already disabled on other big-endian targets.
This patch matches this.
Tested on `sparcv9-sun-solaris2.11`.
Test for #108348 which is almost NFC. However, the test
may fail on some platforms, and a few iterations could be
needed to filter out unsupported platforms.
Previously an attempt to free a null pointer during initialization would
fail on ENSURE_LSAN_INITED assertion (since a null pointer is not owned
by DlsymAlloc).
Almost all sanitizers already support the test.
* Tsan does not use DlsymAlloc yet.
* Lsan will support with #106912.
memprof,rtsan,nsan are not tested as part of
sanitizer_common, but we should keep them here to
show up when it happen.
---------
Co-authored-by: Xiaofeng Tian <110771974+txff99@users.noreply.github.com>
