I grep the code and find that `Abort()` is only called in `Die()` when
the flag `abort_on_error` is set.
Thus, if reserving shadow memory range fails, `Die()` rather than
`Abort()` should be called. In this case, the flag `abort_on_error` will
be respected and the die callbacks will be called.
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.
This reverts commit 69f3244da76586be393d1e97b01660c6f03d666c.
Reason: buildbot breakage because Android doesn't have <gnu/libc-version.h>
https://lab.llvm.org/buildbot/#/builders/186/builds/2381
(It's probably easy to fix but I don't readily have an Android device to test.)
Secondary cache entries are now released to the OS from least recent to
most recent entries. This helps to avoid unnecessary scans of the cache
since entries ready to be released (specifically, entries that are
considered old relative to the configurable release interval) will
always be at the tail of the list of committed entries by the LRU
ordering. For this same reason, the `OldestTime` variable is no longer
needed to indicate when releases are necessary so it has been removed.
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`.
`gnu_get_libc_version` unlike `confstr` is not
intercepted. We should be able to use this
function earier.
Looks like we use `confstr` staring from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038
but there is no specific reason to refer it over
`gnu_get_libc_version`.
Allows unloading and reloading of ignored libraries. We don't attempt to
reuse or free memory of unloaded library. So TSan will assert if an
ignored library is reloaded 128 times.
Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
When enabling ASan testing on SPARC as per PR #107405, two tests `FAIL`
in similar ways as detailed in Issue #108194: at `-O1` and above, one
line of the stacktrace lacks the line number info, causing the tests to
`FAIL`. I could trace this to `clang` generating incomplete line number
info; `g++` gets this right.
To avoid this, this patch `XFAIL`s the affected tests on SPARC.
Tested on `sparcv9-sun-solaris2.11`.
…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`.
When SPARC Asan testing is enabled by PR #107405, many Linux/sparc64
tests just hang like
```
#0 0xf7ae8e90 in syscall () from /usr/lib32/libc.so.6
#1 0x701065e8 in __sanitizer::FutexWait(__sanitizer::atomic_uint32_t*, unsigned int) ()
at compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:766
#2 0x70107c90 in Wait ()
at compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:35
#3 0x700f7cac in Lock ()
at compiler-rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:196
#4 Lock ()
at compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_registry.h:98
#5 LockThreads ()
at compiler-rt/lib/asan/asan_thread.cpp:489
#6 0x700e9c8c in __asan::BeforeFork() ()
at compiler-rt/lib/asan/asan_posix.cpp:157
#7 0xf7ac83f4 in ?? () from /usr/lib32/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```
It turns out that this happens in tests using `internal_fork` (e.g.
invoking `llvm-symbolizer`): unlike most other Linux targets, which use
`clone`, Linux/sparc64 has to use `__fork` instead. While `clone`
doesn't trigger `pthread_atfork` handlers, `__fork` obviously does,
causing the hang.
To avoid this, this patch disables `InstallAtForkHandler` and lets the
ASan tests run to completion.
Tested on `sparc64-unknown-linux-gnu`.
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.
This is only for "real" msvc and is to support running sanitizer tests
with "real" MSVC. Most compiler-rt tests do not yet pass with msvc,
which will be addressed in future PRs for asan, sanitizer_common, and
the fuzzer.
We've been using these changes to lit to run CI for the version of
address sanitizer that ships with MSVC, by upstreaming them we can avoid
being broken by future lit changes and allow contributors (importantly
_us_) to run the MSVC tests on changes developed in the open.
Perform the same macro expansion in the header to improve handling
the various ARM64 environments which use different CPU architecture
identification macro spellings.
`DTLS_on_libc_memalign` is called from primary
allocator, so `__sanitizer_get_allocated_begin`
should also be aware of allocation,
and correctly handled by `GetDTLSRange`.
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>
When clang is used as `clang-cl`, we use MSVC style macros. The spelling
of `__aarch64__` is converted to `_M_ARM64`. Account for this
alternative spelling in the conditional check. While in the area, add a
tertiary spelling of `__arm64__` to ensure that we catch more of the
variants.
With the help of @lhames, This pull request introduces the `dlupdate`
function in the ORC runtime. `dlupdate` enables incremental execution of
new initializers introduced in the REPL environment. Unlike traditional
`dlopen`, which manages initializers, code mapping, and library
reference counts, `dlupdate` focuses exclusively on running new
initializers.
