Defaulting to -Xclang -coverage-version='407*' makes .gcno/.gcda
compatible with gcov [4.7,8)
In addition, delete clang::CodeGenOptionsBase::CoverageExtraChecksum and GCOVOptions::UseCfgChecksum.
We can infer the information from the version.
With this change, .gcda files produced by `clang --coverage a.o` linked executable can be read by gcov 4.7~7.
We don't need other -Xclang -coverage* options.
There may be a mismatching version warning, though.
(Note, GCC r173147 "split checksum into cfg checksum and line checksum"
made gcov 4.7 incompatible with previous versions.)
rL144865 incorrectly wrote function names for GCOV_TAG_FUNCTION
(this might be part of the reasons the header says
"We emit files in a corrupt version of GCOV's "gcda" file format").
rL176173 and rL177475 realized the problem and introduced -coverage-no-function-names-in-data
to work around the issue. (However, the description is wrong.
libgcov never writes function names, even before GCC 4.2).
In reality, the linker command line has to look like:
clang --coverage -Xclang -coverage-version='407*' -Xclang -coverage-cfg-checksum -Xclang -coverage-no-function-names-in-data
Failing to pass -coverage-no-function-names-in-data can make gcov 4.7~7
either produce wrong results (for one gcov-4.9 program, I see "No executable lines")
or segfault (gcov-7).
(gcov-8 uses an incompatible format.)
This patch deletes -coverage-no-function-names-in-data and the related
function names support from libclang_rt.profile
Summary:
This is necessary to handle calls to free() after __hwasan_thread_exit,
which is possible in glibc.
Also, add a null check to GetCurrentThread, otherwise the logic in
GetThreadByBufferAddress turns it into a non-null value. This means that
all of the checks for GetCurrentThread() != nullptr do not have any
effect at all right now!
Reviewers: pcc, hctim
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79608
Summary:
When forking in several threads, the counters were written out in using the same global static variables (see GCDAProfiling.c): that leads to crashes.
So when there is a fork, the counters are resetted in the child process and they will be dumped at exit using the interprocess file locking.
When there is an exec, the counters are written out and in case of failures they're resetted.
Reviewers: jfb, vsk, marco-c, serge-sans-paille
Reviewed By: marco-c, serge-sans-paille
Subscribers: llvm-commits, serge-sans-paille, dmajor, cfe-commits, hiraditya, dexonsmith, #sanitizers, marco-c, sylvestre.ledru
Tags: #sanitizers, #clang, #llvm
Differential Revision: https://reviews.llvm.org/D78477
When reporting diagnostics from ASan's (and other sanitizer's) signal
handlers we should strip the "invalid signature" bit before printing
addresses. This makes the report less confusing and let's the user
focus on the real issue.
rdar://62615826
Reviewed By: kubamracek, delcypher
Differential Revision: https://reviews.llvm.org/D79132
Summary:
Currently, realloc is marked as "discard" in done_abilist.txt. As discussed in PR#45583, this is probably not the expected behavior; a custom wrapper seems to be required. Since this wrapper has not been implemented yet, realloc should not be in the done_abilist.txt file so that a warning is displayed when it is called.
Reviewers: kcc, pcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78379
Summary:
Implement pattern initialization of memory (excluding the secondary
allocator because it already has predictable memory contents).
Expose both zero and pattern initialization through the C API.
Reviewers: pcc, cryptoad
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79133
Summary:
If this is called before the malloc call in a thread (or in the whole
program), the lazy initialization of the allocation can overwrite
Options.
Reviewers: pcc, cryptoad
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79130
Newer iOS SDK introduce accessors to retrieve the register values
(arm_thread_state64_get_*) and disallows direct access to fields. If
arm_thread_state64_get_sp is defined, the accessors are available.
Summary: Fixes an ABI violation in the trampoline code for AArch64 that causes the indirect result register to get overwritten if the XRay handler function is complex enough to use it.
Reviewers: MaskRay, dberris, johnislarry
Subscribers: kristof.beyls, danielkiss, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78596
This is the first patch in a series to add support for the AVR target.
This patch includes changes to make compiler-rt more target independent
by not relying on the width of an int or long.
Differential Revision: https://reviews.llvm.org/D78662
Summary:
Following up the discussion on D77638 (and following rGd6cfed6060c283dc4a6bf9ca294dcd732e8b9f72
as example), defining `__sanitizer_cov_bool_flag_init` as the weak interface
functions in various compiler-rt/ files.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Subscribers: dberris, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D77857
Follow-up of D78082 and D78590.
Otherwise, because xray_instr_map is now read-only, the absolute
relocation used for Sled.Function will cause a text relocation.
Follow-up of D78082 (x86-64).
This change avoids dynamic relocations in `xray_instr_map` for ARM/AArch64/powerpc64le.
MIPS64 cannot use 64-bit PC-relative addresses because R_MIPS_PC64 is not defined.
Because MIPS32 shares the same code, for simplicity, we don't use PC-relative addresses for MIPS32 as well.
Tested on AArch64 Linux and ppc64le Linux.
Reviewed By: ianlevesque
Differential Revision: https://reviews.llvm.org/D78590
Summary: Switch to pc-relative lookup of the xray handler function to avoid text relocations.
Reviewers: MaskRay, dberris, johnislarry
Subscribers: kristof.beyls, danielkiss, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78595
Summary: We load multiple copies of the trampolines into memory when instrumenting DSOs. Hidden visibility prevents conflicts in this scenario.
Reviewers: MaskRay, dberris, johnislarry
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78593
Summary:
While working on rdar://problem/62083617 I noticed this call was
missing.
This is a no-op for all platforms except Darwin. For Darwin this
means the `use_xnu_fast_mmap` flag is initialized as it was intended
when using UBSan in standalone mode.
Reviewers: vitalybuka, vsk, kubamracek, yln, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78532
Summary:
This fixes symbolization in Standalone UBSan mode for the Darwin simulators.
861b69faee (rdar://problem/58789439) tried to fix
symbolization for all sanitizers on Darwin simulators but unfortunately it only
fixed the problem for TSan.
For UBSan in standalone mode the fix wasn't sufficient because UBSan's
standalone init doesn't call `Symbolizer::LateInitialize()` like ASan
and TSan do. This meant that `AtosSymbolizerProcess::LateInitialize()`
was never being called before
`AtosSymbolizerProcess::StartSymbolizerSubprocess()` which breaks an
invariant we expect to hold.
The missing call to `Symbolizer::LateInitialize()` during UBSan's
standalone init seems like an accidently omission so this patch simply
adds it.
rdar://problem/62083617
Reviewers: vitalybuka, kubamracek, yln, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78530
xray_instr_map contains absolute addresses of sleds, which are relocated
by `R_*_RELATIVE` when linked in -pie or -shared mode.
By making these addresses relative to PC, we can avoid the dynamic
relocations and remove the SHF_WRITE flag from xray_instr_map. We can
thus save VM pages containg xray_instr_map (because they are not
modified).
This patch changes x86-64 and bumps the sled version to 2. Subsequent
changes will change powerpc64le and AArch64.
Reviewed By: dberris, ianlevesque
Differential Revision: https://reviews.llvm.org/D78082
Summary:
861b69faee (rdar://problem/58789439) while
fixing symbolization for TSan completely broke ASan's runtime for the
simulators.
The problem with the previous patch is that the memory passed to
`putenv()` was poisoned and when passed to `putenv()` it tripped
an interceptor for `strchr()` which saw the memory was poisoned and
raised an ASan issue.
The memory was poisoned because `AtosSymbolizerProcess` objects
are created using ASan's internal allocator. Memory from this
allocator gets poisoned with `kAsanInternalHeapMagic`.
To workaround this, this patch makes the memory for the environment
variable entry a global variable that isn't poisoned.
This pass also adds a `DCHECK(getenv(K_ATOS_ENV_VAR))` because the
following DCHECK would crash because `internal_strcmp()` doesn't
work on nullptr.
rdar://problem/62067724
Reviewers: kubamracek, yln
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78525
This variable is being used, but it's not being set (it's only set
for ubsan_minimal, but not ubsan). This addresses a regression that
was introduced in D78325.
Differential Revision: https://reviews.llvm.org/D78410
Introduce a function __scudo_get_error_info() that may be called to interpret
a crash resulting from a memory error, potentially in another process,
given information extracted from the crashing process. The crash may be
interpreted as a use-after-free, buffer overflow or buffer underflow.
Also introduce a feature to optionally record a stack trace for each
allocation and deallocation. If this feature is enabled, a stack trace for
the allocation and (if applicable) the deallocation will also be available
via __scudo_get_error_info().
Differential Revision: https://reviews.llvm.org/D77283
Summary:
Due to sandbox restrictions in the recent versions of the simulator runtime the
atos program is no longer able to access the task port of a parent process
without additional help.
This patch fixes this by registering a task port for the parent process
before spawning atos and also tells atos to look for this by setting
a special environment variable.
This patch is based on an Apple internal fix (rdar://problem/43693565) that
unfortunately contained a bug (rdar://problem/58789439) because it used
setenv() to set the special environment variable. This is not safe because in
certain circumstances this can trigger a call to realloc() which can fail
during symbolization leading to deadlock. A test case is included that captures
this problem.
The approach used to set the necessary environment variable is as
follows:
1. Calling `putenv()` early during process init (but late enough that
malloc/realloc works) to set a dummy value for the environment variable.
2. Just before `atos` is spawned the storage for the environment
variable is modified to contain the correct PID.
A flaw with this approach is that if the application messes with the
atos environment variable (i.e. unsets it or changes it) between the
time its set and the time we need it then symbolization will fail. We
will ignore this issue for now but a `DCHECK()` is included in the patch
that documents this assumption but doesn't check it at runtime to avoid
calling `getenv()`.
The issue reported in rdar://problem/58789439 manifested as a deadlock
during symbolization in the following situation:
1. Before TSan detects an issue something outside of the runtime calls
setenv() that sets a new environment variable that wasn't previously
set. This triggers a call to malloc() to allocate a new environment
array. This uses TSan's normal user-facing allocator. LibC stores this
pointer for future use later.
2. TSan detects an issue and tries to launch the symbolizer. When we are in the
symbolizer we switch to a different (internal allocator) and then we call
setenv() to set a new environment variable. When this happen setenv() sees
that it needs to make the environment array larger and calls realloc() on the
existing enviroment array because it remembers that it previously allocated
memory for it. Calling realloc() fails here because it is being called on a
pointer its never seen before.
The included test case closely reproduces the originally reported
problem but it doesn't replicate the `((kBlockMagic)) ==
((((u64*)addr)[0])` assertion failure exactly. This is due to the way
TSan's normal allocator allocates the environment array the first time
it is allocated. In the test program addr[0] accesses an inaccessible
page and raises SIGBUS. If TSan's SIGBUS signal handler is active, the
signal is caught and symbolication is attempted again which results in
deadlock.
In the originally reported problem the pointer is successfully derefenced but
then the assert fails due to the provided pointer not coming from the active
allocator. When the assert fails TSan tries to symbolicate the stacktrace while
already being in the middle of symbolication which results in deadlock.
rdar://problem/58789439
Reviewers: kubamracek, yln
Subscribers: jfb, #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78179
Now that write data continously into the memory mapping, we don't need
to keep the VMO handle around after it has been mapped. This change also
ensures that the VMO is always closed on error.
Differential Revision: https://reviews.llvm.org/D76963
Summary:
Do not reexport libgcc.a symbols and random sanitizer internal symbols
by applying a version script to the shared library build.
This fixes unwinder conflicts on Android that are created by reexporting
the unwinder interface from libgcc_real.a. The same is already done in
asan and hwasan.
Reviewers: vitalybuka, srhines
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78325
Summary:
This is implemented by adding a `Symbolizer::LateInitializeTools()`
method that iterates over the registered tools and calls the
`LateInitialize()` method on them.
`Symbolizer::LateInitializeTools()` is now called from the various
`Symbolizer::LateInitialize()` implementations.
The default implementation of `SymbolizerTool::LateInitialize()`
does nothing so this change should be NFC.
This change allows `SymbolizerTool` implementations to perform
any initialization that they need to perform at the
LateInitialize stage of a sanitizer runtime init.
rdar://problem/58789439
Reviewers: kubamracek, yln, vitalybuka, cryptoad, phosek, rnk
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78178
Fixes:
1. Setting the number of entries in a thread's clock to max between
the thread and the SyncClock the thread is acquiring from
2. Setting last_acquire_
Unit- and stress-test for releaseStoreAcquire added to
tests/unit/tsan_clock_test.cpp
The following declarations were missing a prototype:
FE_ROUND_MODE __fe_getround();
int __fe_raise_inexact();
Discovered while fixing a bug in Clang related to unprototyped function
calls (see the previous commit).
Differential Revision: https://reviews.llvm.org/D78205
Summary:
The function used to log on Android will cut the message past
a certain amount of characters, which mostly materializes when
dumping the size class map on OOM.
This change splits the log message at newline boundaries.
Reviewers: pcc, cferris, hctim, eugenis
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78018
@kamleshbhalui reported that when the Standard Extension M
(Multiplication and Division) is disabled for RISC-V,
`__udivdi3` will call __udivmodti4 which will in turn calls `__udivdi3`.
This patch moves __udivsi3 (shift and subtract) to int_div_impl.inc
`__udivXi3`, optimize a bit, add a `__umodXi3`, and use `__udivXi3` and
`__umodXi3` to define `__udivsi3` `__umodsi3` `__udivdi3` `__umoddi3`.
Reviewed By: kamleshbhalui
Differential Revision: https://reviews.llvm.org/D77912
Summary:
Previously `AtosSymbolizer` would set the PID to examine in the
constructor which is called early on during sanitizer init. This can
lead to incorrect behaviour in the case of a fork() because if the
symbolizer is launched in the child it will be told examine the parent
process rather than the child.
To fix this the PID is determined just before the symbolizer is
launched.
A test case is included that triggers the buggy behaviour that existed
prior to this patch. The test observes the PID that `atos` was called
on. It also examines the symbolized stacktrace. Prior to this patch
`atos` failed to symbolize the stacktrace giving output that looked
like...
```
#0 0x100fc3bb5 in __sanitizer_print_stack_trace asan_stack.cpp:86
#1 0x10490dd36 in PrintStack+0x56 (/path/to/print-stack-trace-in-code-loaded-after-fork.cpp.tmp_shared_lib.dylib:x86_64+0xd36)
#2 0x100f6f986 in main+0x4a6 (/path/to/print-stack-trace-in-code-loaded-after-fork.cpp.tmp_loader:x86_64+0x100001986)
#3 0x7fff714f1cc8 in start+0x0 (/usr/lib/system/libdyld.dylib:x86_64+0x1acc8)
```
After this patch stackframes `#1` and `#2` are fully symbolized.
This patch is also a pre-requisite refactor for rdar://problem/58789439.
Reviewers: kubamracek, yln
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D77623
Summary:
In preparation for writing a test for a bug fix we need to be able to
see the command used to launch the symbolizer process. This feature
will likely be useful for debugging how the Sanitizers use the
symbolizer in general.
This patch causes the command line used to launch the process to be
shown at verbosity level 3 and higher.
A small test case is included.
Reviewers: kubamracek, yln, vitalybuka, eugenis, kcc
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D77622
Summary:
Fuchsia's gcc uses this, which in turn prevents us to compile successfully
due to a few `memset`'ing some non-trivial classes in some `init`.
Change those `memset` to members initialization.
Reviewers: pcc, hctim
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D77902
When creating and destroying fibers in tsan a thread state is created and destroyed. Currently, a memory mapping is leaked with each fiber (in __tsan_destroy_fiber). This causes applications with many short running fibers to crash or hang because of linux vm.max_map_count.
The root of this is that ThreadState holds a pointer to ThreadSignalContext for handling signals. The initialization and destruction of it is tied to platform specific events in tsan_interceptors_posix and missed when destroying a fiber (specifically, SigCtx is used to lazily create the ThreadSignalContext in tsan_interceptors_posix). This patch cleans up the memory by makinh the ThreadState create and destroy the ThreadSignalContext.
The relevant code causing the leak with fibers is the fiber destruction:
void FiberDestroy(ThreadState *thr, uptr pc, ThreadState *fiber) {
FiberSwitchImpl(thr, fiber);
ThreadFinish(fiber);
FiberSwitchImpl(fiber, thr);
internal_free(fiber);
}
Author: Florian
Reviewed-in: https://reviews.llvm.org/D76073
Summary:
Commit b684c1a50f ("Add a `Symbolizer::GetEnvP()` method that allows
symbolizer implementations to customise the environment of the
symbolizer binary.") exposed a latent ARM issue, and that broke
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-full-sh
This coincided with breakage caused by my commit 5f5fb56c68
("[compiler-rt] Intercept the uname() function"), so I had to
investigate.
The issue is that GetArgsAndEnv does not work on ARM: there glibc's
_start overwrites argc value stored at __libc_start_end, breaking the
existing argv/envp parsing logic.
Fix by inferring argc from argv.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: dberris, kristof.beyls, danielkiss, #sanitizers, delcypher
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D77400
Summary:
MSan not implementing COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED looks
like an omission - this macro makes it possible for those intercepted
functions, which libc needs very early, to work before interceptors are
initialized (i.e. before REAL() is usable).
While currently there are no observable practical problems in this
area, changes in libc or in MSan runtime may provoke them. Therefore,
change MSan to work like ASan and TSan already do - use internal
functions in certain interceptors when initialization is not complete.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76969
Fix similar to https://reviews.llvm.org/D77111 but fow Windows.
gotsan.cpp:14071:16: error: missing terminating ' character [-Werror]
case 0b10'010: // c.lwsp (rd != x0)
^
Reported-by: Keith Randall
The intent of the `llvm_gcda_start_file` function is that only
one process create the .gcda file and initialize it to be updated
by other processes later.
Before this change, if multiple processes are started simultaneously,
some of them may initialize the file because both the first and
second `open` calls may succeed in a race condition and `new_file`
becomes 1 in those processes. This leads incorrect coverage counter
values. This often happens in MPI (Message Passing Interface) programs.
The test program added in this change is a simple reproducer.
This change ensures only one process creates/initializes the file by
using the `O_EXCL` flag.
Differential Revision: https://reviews.llvm.org/D76206
The above change used a binary literal that is not supported in c++11 mode when
using gcc. It was formalized into the c++14 standard and works when using that
mode to compile, so change the script to use c++14 instead.
Reviewed by: dvyukov
Differential Revision: https://reviews.llvm.org/D77111
Summary:
Commit 5f5fb56c68 ("[compiler-rt] Intercept the uname() function")
broke sanitizer-x86_64-linux and clang-cmake-thumbv7-full-sh (again)
builds:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/26313http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-full-sh/builds/4324
The reason is that uname() can be called as early as
__pthread_initialize_minimal_internal(). When intercepted, this
triggers ASan initialization, which eventually calls dlerror(), which
in turn uses pthreads, causing all sorts of issues.
Fix by falling back to internal_uname() when interceptor runs before
ASan is initialized. This is only for Linux at the moment.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: dberris, #sanitizers, pcc
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76919
This patch follows the approach also used for MIPS, where we decode the
offending instruction to determine if the fault was caused by a read or
write operation, as that seems to be the only relevant information we have
in the signal context structure to determine that.
Differential Revision: https://reviews.llvm.org/D75168
Summary:
When ASan reports an issue the contents of the system log buffer
(`error_message_buffer`) get flushed to the system log (via
`LogFullErrorReport()`). After this happens the buffer is not cleared
but this is usually fine because the process usually exits soon after
reporting the issue.
However, when ASan runs in `halt_on_error=0` mode execution continues
without clearing the buffer. This leads to problems if more ASan
issues are found and reported.
1. Duplicate ASan reports in the system log. The Nth (start counting from 1)
ASan report will be duplicated (M - N) times in the system log if M is the
number of ASan issues reported.
2. Lost ASan reports. Given a sufficient
number of reports the buffer will fill up and consequently cannot be appended
to. This means reports can be lost.
The fix here is to reset `error_message_buffer_pos` to 0 which
effectively clears the system log buffer.
A test case is included but unfortunately it is Darwin specific because
querying the system log is an OS specific activity.
rdar://problem/55986279
Reviewers: kubamracek, yln, vitalybuka, kcc, filcab
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76749
Summary:
There's no unwinding functionality on Android that allows for line
numbers to be retrieved in-process. As a result, we can't have
this backtrace test run on Android.
Cleanup the test to use optnone functions instead, which is more stable
than line numbers anyway.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: #sanitizers, morehouse, cferris
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76807
Commit 5f5fb56c68 ("[compiler-rt] Intercept the uname() function")
broke clang-cmake-thumbv7-full-sh build:
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-full-sh/builds/4296
This also affects i386.
The reason is that intercepted uname() is called by GetKernelAreaSize()
during ASAN initialization on 32-bit platforms, but the respective
interceptor is not initialized yet at this point, leading to null
pointer dereference.
Introduce internal_uname() wrapper around uname syscall, and use it in
GetKernelAreaSize() and in FixedCVE_2016_2143().
Author: Ilya Leoshkevich
Reviewed By: Evgenii Stepanov
Differential Revision: https://reviews.llvm.org/D76776
Temporarily revert "tsan: fix leak of ThreadSignalContext for fibers"
because it breaks the LLDB bot on GreenDragon.
This reverts commit 93f7743851.
This reverts commit d8a0f76de7.
When creating and destroying fibers in tsan a thread state
is created and destroyed. Currently, a memory mapping is
leaked with each fiber (in __tsan_destroy_fiber).
This causes applications with many short running fibers
to crash or hang because of linux vm.max_map_count.
The root of this is that ThreadState holds a pointer to
ThreadSignalContext for handling signals. The initialization
and destruction of it is tied to platform specific events
in tsan_interceptors_posix and missed when destroying a fiber
(specifically, SigCtx is used to lazily create the
ThreadSignalContext in tsan_interceptors_posix). This patch
cleans up the memory by inverting the control from the
platform specific code calling the generic ThreadFinish to
ThreadFinish calling a platform specific clean-up routine
after finishing a thread.
The relevant code causing the leak with fibers is the fiber destruction:
void FiberDestroy(ThreadState *thr, uptr pc, ThreadState *fiber) {
FiberSwitchImpl(thr, fiber);
ThreadFinish(fiber);
FiberSwitchImpl(fiber, thr);
internal_free(fiber);
}
I would appreciate feedback if this way of fixing the leak is ok.
Also, I think it would be worthwhile to more closely look at the
lifecycle of ThreadState (i.e. it uses no constructor/destructor,
thus requiring manual callbacks for cleanup) and how OS-Threads/user
level fibers are differentiated in the codebase. I would be happy to
contribute more if someone could point me at the right place to
discuss this issue.
Reviewed-in: https://reviews.llvm.org/D76073
Author: Florian (Florian)
tsan while used by golang's race detector was not working on alpine
linux, since it is using musl-c instead of glibc. Since alpine is very
popular distribution for container deployments, having working race
detector would be nice. This commits adds some ifdefs to get it working.
It fixes https://github.com/golang/go/issues/14481 on golang's issue tracker.
Reviewed-in: https://reviews.llvm.org/D75849
Author: graywolf-at-work (Tomas Volf)
This avoids the test failure that was introduced in rG32bddad where
this function pulls in the rest of InstrProfilingFile.c which is
undesirable in use cases when profile runtime is being used without
the rest of libc.
This also allows additional cleanup by eliminating another variable
from platforms that don't need it.
Differential Revision: https://reviews.llvm.org/D76750
On Fuchsia, we always use the continuous mode with runtime counter
relocation, so there's no need for atexit hook or support for dumping
the profile manually.
Differential Revision: https://reviews.llvm.org/D76556
Summary:
This change introduces the `Symbolizer::GetEnvP()` method that returns a
pointer to environment array used for spawning the symbolizer process.
The motivation is to allow implementations to customise the environment
if required. The default implementation just returns
`__sanitizer::GetEnviron()` which (provided it's implemented) should
preserve the existing behaviours of the various implementations.
This change has been plumbed through the `internal_spawn(...)` and
`StartSubprocess(...)` process spawning implementations.
For the `StartSubprocess()` implementation we need to call `execve()`
rather than `execv()` to pass the environment. However, it appears that
`internal_execve(...)` exists in sanitizer_common so this patch use that
which seems like a nice clean up.
Support in the Windows implementation of
`SymbolizerProcess:StartSymbolizerSubprocess()` has not been added
because the Windows sanitizer runtime doesn't implement `GetEnviron()`.
rdar://problem/58789439
Reviewers: kubamracek, yln, dvyukov, vitalybuka, eugenis, phosek, aizatsky, rnk
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76666
Summary:
Backtrace() returns the number of frames that are *available*, rather
than the number of frames stored. When we pack, we supply the number of
frames we have stored. The number of available frames can exceed the
number of stored frames, leading to stack OOB read.
Fix up this problem.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: #sanitizers, morehouse, cferris, pcc
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76722
realeaseAcquire() is a new function added to TSan in support of the Go data-race detector.
It's semantics is:
void ThreadClock::releaseAcquire(SyncClock *sc) const {
for (int i = 0; i < kMaxThreads; i++) {
tmp = clock[i];
clock[i] = max(clock[i], sc->clock[i]);
sc->clock[i] = tmp;
}
}
For context see: https://go-review.googlesource.com/c/go/+/220419
Reviewed-in: https://reviews.llvm.org/D76322
Author: dfava (Daniel Fava)
For MTE error reporting we will need to expose interfaces for crash handlers
to use to interpret scudo headers and metadata. The intent is that these
interfaces will live in scudo/interface.h.
Move the existing interface.h into an include/scudo directory and make it
independent of the internal headers, so that we will be able to add the
interfaces there.
Differential Revision: https://reviews.llvm.org/D76648
struct stack_t on Linux x86_64 has internal padding which may be left
uninitialized. The check should be replaced with multiple checks for
individual fields of the struct. For now, remove the check altogether.
Summary:
Move interceptor from msan to sanitizer_common_interceptors.inc, so that
other sanitizers could benefit.
Adjust FixedCVE_2016_2143() to deal with the intercepted uname().
Patch by Ilya Leoshkevich.
Reviewers: eugenis, vitalybuka, uweigand, jonpa
Reviewed By: eugenis, vitalybuka
Subscribers: dberris, krytarowski, #sanitizers, stefansf, Andreas-Krebbel
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76578
Summary:
We introduced a way to fallback to the immediately larger size class for
the Primary in the event a region was full, but in the event of the largest
size class, we would just fail.
This change allows to fallback to the Secondary when the last region of
the Primary is full. We also expand the trick to all platforms as opposed
to being Android only, and update the test to cover the new case.
Reviewers: hctim, cferris, eugenis, morehouse, pcc
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76430
The VMO size is always page-rounded, but Zircon now provides
a way to publish the precise intended size.
Patch By: mcgrathr
Differential Revision: https://reviews.llvm.org/D76437
While the VMO size is always page aligned, we can record the content
size as a property and then use this metadata when writing the data to
a file.
Differential Revision: https://reviews.llvm.org/D76462
While the VMO size is always page aligned, we can record the content
size as a property and then use this metadata when writing the profile
to a file.
Differential Revision: https://reviews.llvm.org/D76402
Summary:
Some kernels can provide 16EiB worth of mappings to each process, which
causes mmap test to run for a very long time. In order to make it stop
after a few seconds, make mmap_interceptor() fail when the original
mmap() returns an address which is outside of the application range.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: #sanitizers, Andreas-Krebbel, stefansf, jonpa, uweigand
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D76426
arm64e adds support for pointer authentication, which was adopted by
libplatform to harden setjmp/longjmp and friends. We need to teach
the TSan interceptors for those functions about this.
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D76257
https://github.com/apple/swift/pull/30112/ makes the Swift standard
library for iOS build for arm64e. If you're building Swift against your
own LLVM, this in turn requires having the builtins built for arm64e,
otherwise you won't be able to use the builtins (which will in turn lead
to an undefined symbol for `__isOSVersionAtLeast`). Make the builtins
build for arm64e to fix this.
Differential Revision: https://reviews.llvm.org/D76041
Summary:
The `ElfW()` macro is not provided by `<link.h>` on some
systems (e.g., FreeBSD). On these systems the data structures are
just called `Elf_XXX`. Define `ElfW()` locally.
(This fix is taken from [libunwind](9b05596eff/libunwind/src/AddressSpace.hpp (L144-L157)).)
Reviewers: compnerd
Differential revision: https://reviews.llvm.org/D75907
Patch by Zhizhou Yang!
In his own words:
"""
Similar change to CMakeLists as r372312.
After r372209, compiler command line may include argument with quotes:
```
-fprofile-instr-use="/foo/bar.profdata"
```
And it causes a hidden failure with execute_process later: Could not
read profile "/foo/bar.profdata": No such file or directory.
In this particular case, the check for .init_array will fail silently
and creates a PGO-ed binary with bad .init_array section in compiler-rt.
Bug details can be found in PR45022
"""
Differential Revision: https://reviews.llvm.org/D75065
Patch by Zhizhou Yang!
In his own words:
"""
Currently compiler-rt doesn't officially support either PGO
instrumentation or use PGO profdata to build it.
PGO related flags are passed into compiler-rt since rL372209, and
causing bugs: 45022, crbug:1018840
This patch adds several checks in compiler-rt to disable PGO related
flags and provides a flag to turn on PGO for compiler-rt if needed.
"""
Differential Revision: https://reviews.llvm.org/D75499
Implements `__clear_cache` for RISC-V Linux. We can't just use `fence.i` on
Linux, because the Linux thread might be scheduled on another hart, and the
`fence.i` instruction only flushes the icache of the current hart.
Summary:
For the 32b primary, whenever we created a region, we would fill it
all at once (eg: create all the transfer batches for all the blocks
in that region). This wasn't ideal as all the potential blocks in
a newly created region might not be consummed right away, and it was
using extra memory (and release cycles) to keep all those free
blocks.
So now we keep track of the current region for a given class, and
how filled it is, carving out at most `MaxNumBatches` worth of
blocks at a time.
Additionally, lower `MaxNumBatches` on Android from 8 to 4. This
lowers the randomness of blocks, which isn't ideal for security, but
keeps things more clumped up for PSS/RSS accounting purposes.
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D75551
Fangrui Song