For errno spoiling reports we only print the stack
where the signal handler is invoked. And the top
frame is the signal handler function, which is supposed
to give the info for debugging.
But in same cases the top frame can be some common thunk,
which does not give much info. E.g. for Go/cgo it's always
runtime.cgoSigtramp.
Print the signal number.
This is what we can easily gather and it may give at least
some hints regarding the issue.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D121979
Explicitly specify the class name to avoid selecting the wrong Run function, and inherit from the correct Test parent
Differential Revision: https://reviews.llvm.org/D121854
Tests can register multiple allocators, but only the first will initialize since it initializes the TSDRegistrySharedT. Then, destruction of subsequent allocator may end up unmapping a nullptr PrimaryBase with non-zero PrimarySize.
Differential Revision: https://reviews.llvm.org/D121858
-fsanitize-memory-use-after-dtor detects memory access after a
subobject is destroyed but its memory is not yet deallocated.
This is done by poisoning each object memory near the end of its destructor.
Subobjects (members and base classes) do this in their respective
destructors, and the parent class does the same for its members with
trivial destructors.
Inexplicably, base classes with trivial destructors are not handled at
all. This change fixes this oversight by adding the base class poisoning logic
to the parent class destructor.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D119300
After e5822ded56, the call to LargeFunction can be optimized out, as x
is never accessed in main. This is causing the test to fail, because the
out-of-bounds access won't be executed.
Adding an extra read and returning the value should prevent the
optimizer from removing the call.
glibc >= 2.33 uses shared functions for stat family functions.
D111984 added support for non-64 bit variants but they
do not appear to be enough as we have been noticing msan
errors on 64-bit stat variants on Chrome OS.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D121652
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
Fix darwin interface test after D121464. asan_rtl_x86_64.S is not
available on Darwin.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D121636
For ppc64 PIE, it seems that [0xa00000000000,0xc00000000000) may be occupied
which will lead to a segfault in certain kernel configurations
(clang-ppc64le-rhel). Use the `!kUsingConstantSpaceBeg` code path like Fuchsia.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D121257
.thumb_func was not switching mode until [1]
so it did not show up but now that .thumb_func (without argument) is
switching mode, its causing build failures on armv6 ( rpi0 ) even when
build is explicitly asking for this file to be built with -marm (ARM
mode), therefore use DEFINE_COMPILERRT_FUNCTION macro to add function
header which considers arch and mode from compiler cmdline to decide if
the function is built using thumb mode or arm mode.
[1] https://reviews.llvm.org/D101975
Note that it also needs https://reviews.llvm.org/D99282
Reviewed By: peter.smith, MaskRay
Differential Revision: https://reviews.llvm.org/D104183
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
This is a part of optimized callback reverts. This is needed to export the callbacks from the rt-asan libraries.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D121464
At present compiler-rt cross compiles for armv6 ( -march=armv6 ) but includes
dmb instructions which are only available in armv7+ this causes SIGILL on
clang+compiler-rt compiled components on rpi0w platforms.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D99282
The false positive fixed by commit f831d6fc80
("tsan: fix false positive during fd close") still happens episodically
on the added more stressful test which does just open/close.
I don't have a coherent explanation as to what exactly happens
but the fix fixes the false positive on this test as well.
The issue may be related to lost writes during asynchronous MADV_DONTNEED.
I've debugged similar unexplainable false positive related to freed and
reused memory and at the time the only possible explanation I found is that
an asynchronous MADV_DONTNEED may lead to lost writes. That's why commit
302ec7b9bc ("tsan: add memory_limit_mb flag") added StopTheWorld around
the memory flush, but unfortunately the commit does not capture these findings.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D121363
Use the correct types for OFF_T, __sanitizer_time_t and
__sanitizer_dirent and forward time_t related functions
to fix using compiler-rt with 32-bit musl libc.
Also redirect the time_t functions that are affected by
https://musl.libc.org/time64.html to use their 64-bit
ABI names.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D119358
follow up to 0a4dec6cc2.
add unsupported for s390 (SEGV)
restore line that s390 complains, so following asserts work.
Differential Revision: https://reviews.llvm.org/D121326
FdClose is a subjet to the same atomicity problem as MemoryRangeFreed
(memory state is not "monotoic" wrt race detection).
So we need to lock the thread slot in FdClose the same way we do
in MemoryRangeFreed.
This fixes the modified stress.cpp test.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D121143
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
This fixes a warning about comparing mismatched types. Since `mmap()` already returns a `void *` use that as the pointer type for comparison.
Reviewed By: kyulee, zequanwu
Differential Revision: https://reviews.llvm.org/D120945
Frederic Cambus