The runtime calls `MaybeDemangleGlobalName` for error reporting and
`__cxxabiv1::__cxa_demangle` is called if available, so demanging Itanium
mangled names in global metadata is unnecessary and wastes data size.
Add `MaybeDemangleGlobalName` in ODR violation detection to support demangled
names in a suppressions file. `MaybeDemangleGlobalName` may call
`DemangleCXXABI` and leak memory. Use an internal allocation to prevent lsan
leak (in case there is no fatal asan error).
The debug feature `report_globals=2` prints information for all instrumented
global variables. `MaybeDemangleGlobalName` would be slow, so don't do that.
The output looks like `Added Global[0x56448f092d60]: beg=0x56448fa66d60 size=4/32 name=_ZL13test_global_2`
and I think the mangled name is fine.
Other mangled schemes e.g. Windows (see win-string-literal.ll) remain the
current behavior.
Reviewed By: hctim
Differential Revision: https://reviews.llvm.org/D138095
Because the call to `dlerror()` may actually want to print something, which turns into a deadlock
as showcased in #49223.
Instead rely on further call to dlsym to clear `dlerror` internal state if they
need to check the return status.
Differential Revision: https://reviews.llvm.org/D128992
Repalce the fixed buffer in SymbolizerProcess with InternalScopedString,
and simply append to it when reading data.
Fixes#55460
Reviewed By: vitalybuka, leonardchan
Differential Revision: https://reviews.llvm.org/D126580
This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)
Performed a global search/replace as in title against LLVM sources
Differential Revision: https://reviews.llvm.org/D126263
This option is per process anyway. I'd like to add more options, but
having them as parameters of __sanitizer_symbolize_code looks
inconvenient.
Reviewed By: browneee
Differential Revision: https://reviews.llvm.org/D116201
A while ago we added some code to the sanitizer runtimes for iOS
simulators to allow `atos` (external process) to inspect the sanitized
process during report generation to enable symbolication. This was done
by setting the `__check_mach_ports_lookup` env var early during process
startup which came with a couple of complications.
This workaround is not required anymore and removing it fixes TSan in
the iOS simulator after the new TSan runtime landed.
(https://reviews.llvm.org/D112603)
Relevant/reverted revisions:
https://reviews.llvm.org/D78178https://reviews.llvm.org/D78179https://reviews.llvm.org/D78525
rdar://86472733
Differential Revision: https://reviews.llvm.org/D115767
Some linux distributions produce versioned llvm-symbolizer binaries,
e.g. my llvm-11 installation puts the symbolizer binary at
/usr/bin/llvm-symbolizer-11.0.0 . However if you then try to run
a binary containing ASAN with
ASAN_SYMBOLIZER_PATH=..../llvm-symbolizer-FOO , it will fail on startup
with "isn't a known symbolizer".
Although it is possible to work around this by setting up symlinks,
that's kindof ugly - supporting versioned binaries is a nicer solution.
(There are now multiple stack overflow and blog posts talking about
this exact issue :) .)
Originally added in:
https://reviews.llvm.org/D8285
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D97682
We want way to set a path to llvm-symbolizer that isn't relative
to the current working directory; this change adds a variable that
expands to the path relative to the current binary.
This approach came from comments in https://reviews.llvm.org/D93070
Differential Revision: https://reviews.llvm.org/D94563
The Swift symbol name prefix has changed from `_T0` to `_$s` as
documented here [1]. This prevents Swift names from properly being
symbolicated when using the in-process LLVM symbolizer. The best way to
fix this seems to be to avoid the duplication of "Is this a Swift symbol
name?" here. We can simply remove this check as `swift_demangle`
already returns null for non-Swift names [2,3].
The check was included in the initial support for Swift name demangling
to avoid superfluous calls to `dlsym()` [4]. A subsequent commit
changed this logic to retrieve the `swift_demangle` function pointer
eagerly during sanitizer initialization, but did not remove the check
[5].
[1] https://github.com/apple/swift/blob/master/docs/ABI/Mangling.rst
[2] b5a8b518ea/include/swift/Demangling/Demangle.h (L643)
[3] b5a8b518ea/stdlib/public/runtime/Demangle.cpp (L656)
[4] https://reviews.llvm.org/D19135
[5] https://reviews.llvm.org/D20015
rdar://62753845
Reviewers: kubamracek, delcypher, dcoughlin, samsonov, thakis
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D81705
Summary:
Currently, there is no way to let the `InternalSymbolizer` implemented
functions know if inline frames should be symbolized. This patch updates
the function `__sanitizer_symbolize_code` to include a parameter for
this ASAN option and toggle between LLVM symbolization functions when
appropriate.
Fixes the following two failing tests when internal symbolization is
enabled:
```
SanitizerCommon-*-x86_64-Linux :: print-stack-trace.cpp
SanitizerCommon-*-x86_64-Linux :: symbolize_pc_inline.cpp
```
Reviewers: vitalybuka, kcc, filcab
Reviewed By: vitalybuka
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79280
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
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:
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
On Darwin, we currently use forkpty to communicate with the "atos"
symbolizer. There are several problems that fork[pty] has, e.g. that
after fork, interceptors are still active and this sometimes causes
crashes or hangs. This is especially problematic for TSan, which uses
interceptors for OS-provided locks and mutexes, and even Libc functions
use those.
This patch replaces forkpty with posix_spawn on Darwin. Since
posix_spawn doesn't fork (at least on Darwin), the interceptors are not
a problem. Another benefit is that we'll handle post-fork failures (e.g.
sandbox disallows "exec") gracefully now.
Related revisions and previous attempts that were blocked by or had to
be revered due to test failures:
https://reviews.llvm.org/D48451https://reviews.llvm.org/D40032
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D65253
llvm-svn: 368947
See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran
for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done
and manually updated (many) references to renamed files found by that.
llvm-svn: 367463
Fangrui Song