Summary:
This is needed because on some platforms we can't install signal
handlers and so the application just traps (i.e. crashes) rather than being intercepted
by ASan's signal handler which in the default Darwin config doesn't
exit with a crashing exit code.
rdar://problem/57984547
Reviewers: yln, kubamracek, jfb
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D71573
Summary:
The sanitizer symbolizers support printing the function offset
(difference between pc and function start) of a stackframe using the
`%q` format specifier.
Unfortunately this didn't actually work because neither the atos
or dladdr symbolizer set the `AddressInfo::function_offset` field.
This patch teaches both symbolizers to try to compute the function
offset. In the case of the atos symbolizer, atos might not report the
function offset (e.g. it reports a source location instead) so in this
case it fallsback to using `dladdr()` to compute the function offset.
Two test cases are included.
rdar://problem/56695185
Reviewers: kubamracek, yln
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69549
coverage-fork.cpp uses `fork()` which requires additional permissions
in the iOS simulator sandbox. We cannot use `sandbox-exec` to grant
these permissions since this is a Posix (not Darwin) test.
This is a patch to support D66328, which was reverted until this lands.
Enable a compiler-rt test that used to fail previously with D66328.
Differential Revision: https://reviews.llvm.org/D67283
Fallout from:
[clang] Report sanitizer blacklist as a dependency in cc1
Default blacklists are now passed via -fsanitize-system-blacklist from driver to cc1.
Summary:
Sometimes an allocation stack trace is not very informative. Provide a
way to replace it with a stack trace of the user's choice.
Reviewers: pcc, kcc
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69208
After r375041 llvm-symbolizer uses it for demangling instead of
UnDecorateSymbolName. LLVM puts spaces after commas while Microsoft does
not.
llvm-svn: 375147
Updated: Removed offending TODO comment.
Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address). The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.
Because of this ASan lies and says that those cases are null
dereferences. This downgrades the severity of a found bug in terms of
security. In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.
rdar://50366151
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68676
> llvm-svn: 374265
llvm-svn: 374384
Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address). The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.
Because of this ASan lies and says that those cases are null
dereferences. This downgrades the severity of a found bug in terms of
security. In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.
rdar://50366151
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68676
llvm-svn: 374265
This is what the original bug (http://llvm.org/PR39641) and the fix
in https://reviews.llvm.org/D63877 have been about.
With the dynamic runtime the test only passes when the asan library
is linked against libstdc++: In contrast to libc++abi, it does not
implement __cxa_rethrow_primary_exception so the regex matches the
line saying that asan cannot intercept this function. Indeed, there
is no message that the runtime failed to intercept __cxa_throw.
Differential Revision: https://reviews.llvm.org/D67298
llvm-svn: 371336
It turns out that the DarwinSymbolizer does not print the "in" part for
invalid files but instead prints
#0 0xabcdabcd (.../asan-symbolize-bad-path.cpp.tmp/bad/path:i386+0x1234)
This tests is only checking that asan_symbolize.py doesn't hang or crash,
so further relax the checks to ensure that the test passes on macOS.
llvm-svn: 370243
I accidentally made the CHECK line stricter when committing D65322.
While it happens to work for Linux and FreeBSD, it broke on Darwin.
This commit restores the previous behaviour.
llvm-svn: 370110
It is possible that addr2line returns a valid function and file name for
the passed address on some build configuations.
The test is only checking that asan_symbolize doesn't assert any more when
passed a valid file with an invalid address so there is no need to check
that it can't find a valid function name.
This should fix http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux
llvm-svn: 370021
Summary:
Currently, llvm-symbolizer will print -1 when presented with -1 and not
print a second line. In that case we will block for ever trying to read
the file name. This also happens for non-existent files, in which case GNU
addr2line exits immediate, but llvm-symbolizer does not (see
https://llvm.org/PR42754). While touching these lines, I also added some
more debug logging to help diagnose this and potential future issues.
Reviewers: kcc, eugenis, glider, samsonov
Reviewed By: eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D65322
llvm-svn: 369924
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
Summary:
This bug occurred when a plug-in requested that a binary not be
symbolized while the script is trying to symbolize a stack frame. In
this case `self.frame_no` would not be incremented. This would cause
subsequent stack frames that are symbolized to be incorrectly numbered.
To fix this `get_symbolized_lines()` has been modified to take an
argument that indicates whether the stack frame counter should
incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)`
is now used in in the case where we don't want to symbolize a line so
that we can keep the frame counter increment in a single function.
A test case is included. The test uses a dummy plugin that always asks
`asan_symbolize.py` script to not symbolize the first binary that the
script asks about. Prior to the patch this would cause the output to
script to look something like
```
#0 0x0
#0 0x0 in do_access
#1 0x0 in main
```
This is the second attempt at landing this patch. The first (r368373)
failed due to failing some android bots and so was reverted in r368472.
The new test is now disabled for Android. It turns out that the patch
also fails for iOS too so it is also disabled for that family of
platforms too.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65495
llvm-svn: 368603
Summary:
This bug occurred when a plug-in requested that a binary not be
symbolized while the script is trying to symbolize a stack frame. In
this case `self.frame_no` would not be incremented. This would cause
subsequent stack frames that are symbolized to be incorrectly numbered.
To fix this `get_symbolized_lines()` has been modified to take an
argument that indicates whether the stack frame counter should
incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)`
is now used in in the case where we don't want to symbolize a line so
that we can keep the frame counter increment in a single function.
A test case is included. The test uses a dummy plugin that always asks
`asan_symbolize.py` script to not symbolize the first binary that the
script asks about. Prior to the patch this would cause the output to
script to look something like
```
#0 0x0
#0 0x0 in do_access
#1 0x0 in main
```
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65495
llvm-svn: 368373
Summary:
MSAN was broken on FreeBSD by https://reviews.llvm.org/D55703: after this
change accesses to the key variable call __tls_get_addr, which is
intercepted. The interceptor then calls GetCurrentThread which calls
MsanTSDGet which again calls __tls_get_addr, etc...
Using the default implementation in the SANITIZER_FREEBSD case fixes MSAN
for me.
I then applied the same change to ASAN (introduced in https://reviews.llvm.org/D55596)
but that did not work yet. In the ASAN case, we get infinite recursion
again during initialization, this time because calling pthread_key_create() early on
results in infinite recursion. pthread_key_create() calls sysctlbyname()
which is intercepted but COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED returns
true, so the interceptor calls internal_sysctlbyname() which then ends up
calling the interceptor again. I fixed this issue by using dlsym() to get
the libc version of sysctlbyname() instead.
This fixes https://llvm.org/PR40761
Reviewers: vitalybuka, krytarowski, devnexen, dim, bsdjhb, #sanitizers, MaskRay
Reviewed By: MaskRay
Subscribers: MaskRay, emaste, kubamracek, jfb, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D65221
llvm-svn: 367442
AddressSanitizer-*-sunos :: TestCases/intercept-rethrow-exception.cc currently FAILs
on Solaris. This happens because std::rethrow_exception cannot be intercepted, as
detailed in Bug 42703.
To account for this and reduce testsuite noise, this patch XFAILs the test.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D65056
llvm-svn: 367293
Under certain execution conditions, the `not` command binds to the command the
output is piped to rather than the command piping the output. In this case, that
flips the return code of the FileCheck invocation, causing a failure when
FileCheck succeeds.
llvm-svn: 366805
cl.exe doesn't understand it; there's /Od instead. See also the review
thread for r229575.
Update lots of compiler-rt tests to use -Od instead of -O0.
Ran `rg -l 'clang_cl.*O0' compiler-rt/test/ | xargs sed -i -c 's/-O0/-Od/'`
Differential Revision: https://reviews.llvm.org/D64506
llvm-svn: 365724
- Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
- Adds unit tests for the new interceptors and expands HeapAlloc
tests to demonstrate new functionality.
Reviewed as D62927
- adds fixes for ~win and x64 tests
> llvm-svn: 365381
llvm-svn: 365424
- Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
- Adds unit tests for the new interceptors and expands HeapAlloc
tests to demonstrate new functionality.
Reviewed as D62927
llvm-svn: 365422
- Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
- Adds unit tests for the new interceptors and expands HeapAlloc
tests to demonstrate new functionality.
Reviewed as D62927
llvm-svn: 365381
These lit configuration files are really Python source code. Using the
.py file extension helps editors and tools use the correct language
mode. LLVM and Clang already use this convention for lit configuration,
this change simply applies it to all of compiler-rt.
Reviewers: vitalybuka, dberris
Differential Revision: https://reviews.llvm.org/D63658
llvm-svn: 364591
These tests won't necessarily work because the reported modules paths
from the device don't match what's on the host and so offline
symbolization fails.
llvm-svn: 363641
Dan Liew