Commit Graph

2550 Commits

Author SHA1 Message Date
Dan Liew f3a089506f Temporarily disable the following failing tests on Darwin:
AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.LongJmpTest
  AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.SigLongJmpTest
  AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.LongJmpTest
  AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.SigLongJmpTest

These failures will be examined properly when time permits.

rdar://problem/62141412
2020-05-27 19:32:06 -07:00
Dan Liew 5811f3a9f8 [asan_symbolize] Fix bug handling C++ symbols when using Atos.
Summary:
The previous code tries to strip out parentheses and anything in between
them. I'm guessing the idea here was to try to drop any listed arguments
for the function being symbolized. Unfortunately this approach is broken
in several ways.

* Templated functions may contain parentheses. The existing approach
messes up these names.
* In C++ argument types are part of a function's signature for the
purposes of overloading so removing them could be confusing.

Fix this simply by not trying to adjust the function name that comes
from `atos`.

A test case is included.

Without the change the test case produced output like:

```
WRITE of size 4 at 0x6060000001a0 thread T0
    #0 0x10b96614d in IntWrapper<void >::operator=> const&) asan-symbolize-templated-cxx.cpp:10
    #1 0x10b960b0e in void writeToA<IntWrapper<void > >>) asan-symbolize-templated-cxx.cpp:30
    #2 0x10b96bf27 in decltype>)>> >)) std::__1::__invoke<void >), IntWrapper<void > >>), IntWrapper<void >&&) type_traits:4425
    #3 0x10b96bdc1 in void std::__1::__invoke_void_return_wrapper<void>::__call<void >), IntWrapper<void > >>), IntWrapper<void >&&) __functional_base:348
    #4 0x10b96bd71 in std::__1::__function::__alloc_func<void >), std::__1::allocator<void >)>, void >)>::operator>&&) functional:1533
    #5 0x10b9684e2 in std::__1::__function::__func<void >), std::__1::allocator<void >)>, void >)>::operator>&&) functional:1707
    #6 0x10b96cd7b in std::__1::__function::__value_func<void >)>::operator>&&) const functional:1860
    #7 0x10b96cc17 in std::__1::function<void >)>::operator>) const functional:2419
    #8 0x10b960ca6 in Foo<void >), IntWrapper<void > >::doCall>) asan-symbolize-templated-cxx.cpp:44
    #9 0x10b96088b in main asan-symbolize-templated-cxx.cpp:54
    #10 0x7fff6ffdfcc8 in start (in libdyld.dylib) + 0
```

Note how the symbol names for the frames are messed up (e.g. #8, #1).

With the patch the output looks like:

```
WRITE of size 4 at 0x6060000001a0 thread T0
    #0 0x10005214d in IntWrapper<void (int)>::operator=(IntWrapper<void (int)> const&) asan-symbolize-templated-cxx.cpp:10
    #1 0x10004cb0e in void writeToA<IntWrapper<void (int)> >(IntWrapper<void (int)>) asan-symbolize-templated-cxx.cpp:30
    #2 0x100057f27 in decltype(std::__1::forward<void (*&)(IntWrapper<void (int)>)>(fp)(std::__1::forward<IntWrapper<void (int)> >(fp0))) std::__1::__invoke<void (*&)(IntWrapper<void (int)>), IntWrapper<void (int)> >(void (*&)(IntWrapper<void (int)>), IntWrapper<void (int)>&&) type_traits:4425
    #3 0x100057dc1 in void std::__1::__invoke_void_return_wrapper<void>::__call<void (*&)(IntWrapper<void (int)>), IntWrapper<void (int)> >(void (*&)(IntWrapper<void (int)>), IntWrapper<void (int)>&&) __functional_base:348
    #4 0x100057d71 in std::__1::__function::__alloc_func<void (*)(IntWrapper<void (int)>), std::__1::allocator<void (*)(IntWrapper<void (int)>)>, void (IntWrapper<void (int)>)>::operator()(IntWrapper<void (int)>&&) functional:1533
    #5 0x1000544e2 in std::__1::__function::__func<void (*)(IntWrapper<void (int)>), std::__1::allocator<void (*)(IntWrapper<void (int)>)>, void (IntWrapper<void (int)>)>::operator()(IntWrapper<void (int)>&&) functional:1707
    #6 0x100058d7b in std::__1::__function::__value_func<void (IntWrapper<void (int)>)>::operator()(IntWrapper<void (int)>&&) const functional:1860
    #7 0x100058c17 in std::__1::function<void (IntWrapper<void (int)>)>::operator()(IntWrapper<void (int)>) const functional:2419
    #8 0x10004cca6 in Foo<void (IntWrapper<void (int)>), IntWrapper<void (int)> >::doCall(IntWrapper<void (int)>) asan-symbolize-templated-cxx.cpp:44
    #9 0x10004c88b in main asan-symbolize-templated-cxx.cpp:54
    #10 0x7fff6ffdfcc8 in start (in libdyld.dylib) + 0
```

rdar://problem/58887175

Reviewers: kubamracek, yln

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D79597
2020-05-19 16:08:09 -07:00
Dan Liew 445b810fbd [ASan] Fix issue where system log buffer was not cleared after reporting an issue.
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
2020-03-26 10:56:17 -07:00
Jordan Rupprecht 3f7d0e7e31 [NFC][compiler-rt][test] Fully qualify string -> std::string 2020-02-19 08:59:26 -08:00
Shoaib Meenai d8f6950828 [asan] Fix test compilation on Android API <= 17
mlockall and munlockall were introduced in Android API 17, so avoid
referencing them on prior versions.

Differential Revision: https://reviews.llvm.org/D73515
2020-01-28 14:36:19 -08:00
Roland McGrath 90a10f00ff [lsan] Support LeakSanitizer runtime on Fuchsia
Support LeakSanitizer runtime on Fuchsia.

Patch By: mcgrathr

Differential Revision: https://reviews.llvm.org/D72887
2020-01-28 11:34:53 -08:00
Petr Hosek 2533bc2361 Revert "[lsan] Support LeakSanitizer runtime on Fuchsia"
This reverts commit d59e3429f3.
2020-01-28 00:24:41 -08:00
Roland McGrath d59e3429f3 [lsan] Support LeakSanitizer runtime on Fuchsia
Support LeakSanitizer runtime on Fuchsia.

Patch By: mcgrathr

Differential Revision: https://reviews.llvm.org/D72887
2020-01-27 23:35:06 -08:00
Alexandre Ganea efad56b2be Remove unused variables, as suggested by @mcgov.
Fixes warning: unused variable 'XXX' [-Wunused-const-variable]
2019-11-04 14:55:51 -05:00
Evgenii Stepanov cd751bcd52 [asan] Fix lint failure in asan_interface.h 2019-10-31 13:58:55 -07:00
Evgenii Stepanov 13e04607f7 [asan] Provide an interface to update an allocation stack trace.
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
2019-10-31 13:54:46 -07:00
Matt Morehouse 7904bd9409 [sanitizer_common] Create max_allocation_size_mb flag.
Summary:
The flag allows the user to specify a maximum allocation size that the
sanitizers will honor.  Any larger allocations will return nullptr or
crash depending on allocator_may_return_null.

Reviewers: kcc, eugenis

Reviewed By: kcc, eugenis

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D69576
2019-10-30 11:26:05 -07:00
Julian Lettner 99c9d7bd63 Reland "[ASan] Do not misrepresent high value address dereferences as null dereferences"
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
2019-10-10 17:19:58 +00:00
Russell Gallop c48e0873af Revert "[ASan] Do not misrepresent high value address dereferences as null dereferences"
As it was breaking bots running sanitizer lint check

This reverts r374265 (git b577efe456)

llvm-svn: 374308
2019-10-10 10:56:52 +00:00
Julian Lettner b577efe456 [ASan] Do not misrepresent high value address dereferences as null dereferences
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
2019-10-10 00:33:04 +00:00
Vitaly Buka d39e7e2cf1 [compiler-rt] Use GetNextInstructionPc in signal handlers
Summary:
All other stack trace callers assume that PC contains return address.
HWAsan already use GetNextInstructionPc in similar code.

PR43339

Reviewers: eugenis, kcc, jfb

Subscribers: dexonsmith, dberris, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D68313

llvm-svn: 373529
2019-10-02 21:20:37 +00:00
Jinsong Ji e2af0e5ee8 [compiler-rt] Fix lint check failure on comments
This fixes buildbot failures for https://reviews.llvm.org/rL372459.
(at least on PowerPC/Z )

The fix is generated by running clang-format on the error lines only.

llvm-svn: 372511
2019-09-22 15:31:03 +00:00
Kamil Rytarowski 1b58389428 Add __lsan::ScopedInterceptorDisabler for strerror(3)
Summary:
strerror(3) on NetBSD uses internally TSD with a destructor that is never
fired for exit(3). It's correctly called for pthread_exit(3) scenarios.

This is a case when a leak on exit(3) is expected, unavoidable and harmless.

Reviewers: joerg, vitalybuka, dvyukov, mgorny

Reviewed By: vitalybuka

Subscribers: dmgreen, kristof.beyls, jfb, llvm-commits, #sanitizers

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D67337

llvm-svn: 372461
2019-09-21 07:45:02 +00:00
Kamil Rytarowski 8827047551 Stop tracking atexit/__cxa_atexit/pthread_atfork allocations in LSan/NetBSD
Summary:
The atexit(3) and __cxa_atexit() calls allocate internally memory and free on exit,
after executing all callback. This causes false positives as DoLeakCheck() is called
from the atexit handler. In the LSan/ASan tests there are strict checks triggering
false positives here.

Intercept all atexit(3) and __cxa_atexit() calls and disable LSan when calling the
real functions.

Stop tracing allocations in pthread_atfork(3) funtions, as there are performed
internal allocations that are not freed for the time of running StopTheWorld()
code. This avoids false-positives.

The same changes have to be replicated in the ASan and LSan runtime.

Non-NetBSD OSs are not tested and this code is restricted to NetBSD only.

Reviewers: dvyukov, joerg, mgorny, vitalybuka, eugenis

Reviewed By: vitalybuka

Subscribers: jfb, llvm-commits, #sanitizers

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D67331

llvm-svn: 372459
2019-09-21 07:30:42 +00:00
David Bolvansky 9a14ee81d2 Remove asan test for strncat(x, y, 0)
llvm-svn: 372143
2019-09-17 17:17:30 +00:00
David Bolvansky 5abd6f46ae [ASAN] Adjust asan tests due to new optimizations
llvm-svn: 372141
2019-09-17 17:07:31 +00:00
Vitaly Buka d2af368aee [compiler-rt] Remove some cpplint filters
llvm-svn: 371704
2019-09-12 02:20:36 +00:00
Vitaly Buka a3cd67c007 [compiler-rt] Better lint output for .inc files
llvm-svn: 371702
2019-09-12 01:35:09 +00:00
Vitaly Buka c0fa632236 Remove NOLINTs from compiler-rt
llvm-svn: 371687
2019-09-11 23:19:48 +00:00
Vitaly Buka 48eb4a27d1 Update compiler-rt cpplint.py
adb3500107

llvm-svn: 371675
2019-09-11 21:33:06 +00:00
Alexander Richardson 677c6ddd33 [asan_symbolize] Fix broken pipe handling for python 2.7
I D65322 I added a check for BrokenPipeError. However, python 2.7 doesn't
have BrokenPipeError. To be python 2.7 and 3 compatible we need to catch
IOError instead and check for errno == errno.EPIPE.

llvm-svn: 370025
2019-08-27 07:27:41 +00:00
David Carlier 4797f68b15 [Sanitizer] Using huge page on FreeBSD for shadow mapping
- Unless explicit configuration, using FreeBSD super pages feature for shadow mapping.
- asan only for now.

Reviewers: dim, emaste, vitalybuka

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D65851

llvm-svn: 370008
2019-08-27 04:02:19 +00:00
Alexander Richardson 2511b5a463 [asan_symbolize] Attempt to fix build-bot failure after latest change
llvm-svn: 369929
2019-08-26 17:11:25 +00:00
Alexander Richardson e320db434e [asan_symbolize] Avoid blocking when llvm-symbolizer is installed as addr2line
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
2019-08-26 16:22:04 +00:00
David Carlier e2ed800d62 [Sanitizer] checks ASLR on FreeBSD
- Especially MemorySanitizer fails if those sysctl configs are enabled.

Reviewers: vitalybuka, emaste, dim

Reviewed By: dim

Differential Revision: https://reviews.llvm.org/D66582

llvm-svn: 369708
2019-08-22 21:36:35 +00:00
Vitaly Buka 93a3cbc746 Revert r369472 and r369441
check-sanitizer does not work on Linux

llvm-svn: 369495
2019-08-21 05:06:21 +00:00
Sebastian Pop 5a7bba09ac [AArch64][asan] fix typo in AsanStats::Print
This created an infinite loop that timed out several build bots while
executing the test in compiler-rt/test/asan/TestCases/atexit_stats.cpp

Differential Revision: https://reviews.llvm.org/D60243

llvm-svn: 369472
2019-08-20 23:28:05 +00:00
Sebastian Pop 63487bfec9 [AArch64] Speed-up leak and address sanitizers on AArch64 for 48-bit VMA
This patch fixes https://github.com/google/sanitizers/issues/703
On a Graviton-A1 aarch64 machine with 48-bit VMA,
the time spent in LSan and ASan reduced from 2.5s to 0.01s when running

clang -fsanitize=leak compiler-rt/test/lsan/TestCases/sanity_check_pure_c.c && time ./a.out
clang -fsanitize=address compiler-rt/test/lsan/TestCases/sanity_check_pure_c.c && time ./a.out

With this patch, LSan and ASan create both the 32 and 64 allocators and select
at run time between the two allocators following a global variable that is
initialized at init time to whether the allocator64 can be used in the virtual
address space.

Differential Revision: https://reviews.llvm.org/D60243

llvm-svn: 369441
2019-08-20 20:54:05 +00:00
Dan Liew c3b93bed29 [asan_symbolize] Fix bug where the frame counter was not incremented.
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
2019-08-12 18:51:25 +00:00
Mitch Phillips cace571c91 Revert "[asan_symbolize] Fix bug where the frame counter was not incremented."
This reverts commit 52a36fae2a.

This commit broke the sanitizer_android buildbot. See comments at
https://reviews.llvm.org/rL368373 for more details.

llvm-svn: 368472
2019-08-09 19:36:41 +00:00
Dan Liew 52a36fae2a [asan_symbolize] Fix bug where the frame counter was not incremented.
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
2019-08-09 00:52:07 +00:00
Kamil Rytarowski 72c940417a Restrict the NetBSD ASan TSD fallback to !ASAN_DYNAMIC
The fallback to the alternative implementation of TSD with TLS
is only needed for the static version of ASan for NetBSD.

The same code cannot be reused for the dynamic version of ASan as
TLS breaks and TSD code works.

llvm-svn: 368219
2019-08-07 21:56:43 +00:00
David Carlier 1d92925a5a [Sanitizer] Linux refactor shadow huge page mode handling
Disabling Transparent huge page mode refactored in one function.

Reviewers: vitalybuka

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D65771

llvm-svn: 367925
2019-08-05 20:54:36 +00:00
Nico Weber 673dc3d4a0 compiler-rt: Rename cc files below test/asan to cpp
See r367803 and similar other changes.

llvm-svn: 367887
2019-08-05 16:48:12 +00:00
Nico Weber f3750a4420 Try to fix OOB tests more on Windows after r367642
See PR42868 for more details.

The affected list of tests is:

Failing Tests (8):
    AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.LargeOOBRightTest
    AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOBRightTest
    AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOB_char
    AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOB_int
    AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.LargeOOBRightTest
    AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOBRightTest
    AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOB_char
    AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOB_int

llvm-svn: 367874
2019-08-05 15:10:15 +00:00
Nico Weber 997d626de6 Try to fix OOB tests on at least Windows after r367642
gtest's built-in regex engine doesn't support (). Looks like it's not
needed, just remove it.

See PR42868 for more details.

llvm-svn: 367873
2019-08-05 15:04:20 +00:00
Vitaly Buka 74296c99b3 Fix flaky test caused by PR42868
llvm-svn: 367642
2019-08-02 02:27:04 +00:00
Nico Weber 4a1a113a99 Remove a few straggler ".cc"s in compiler-rt/lib
llvm-svn: 367589
2019-08-01 17:53:25 +00:00
Nico Weber b47455b573 compiler-rt: Rename .cc file in lib/asan/tests to .cpp
Like r367463, but for asan/tests

llvm-svn: 367559
2019-08-01 13:48:31 +00:00
Nico Weber 217222abea compiler-rt: Rename .cc file in lib/asan to .cpp
Like r367463, but for asan.

llvm-svn: 367558
2019-08-01 13:43:28 +00:00
Alexander Richardson a4ea27de92 [Sanitizer][ASAN][MSAN] Fix infinite recursion on FreeBSD
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
2019-07-31 16:31:55 +00:00
Dan Liew 62a8728750 [asan_symbolize] More debugging output
When a line fails to match the stackframe regex we now report
it in the log.

rdar://problem/49476995

llvm-svn: 367380
2019-07-31 00:59:10 +00:00
Dan Liew 51b1d858d3 [asan_symbolize] Add `--skip-uuid-validation` option to `ModuleMapPlugIn`.
This option disables the validation of binary UUIDs. This is useful
in environments where the `otool` binary is not available.

rdar://problem/49476995

llvm-svn: 367379
2019-07-31 00:59:10 +00:00
Dan Liew 23fd828d4e [asan_symbolize] Provide better error message when extracting the UUID of a binary fails
rdar://problem/49476995

llvm-svn: 367378
2019-07-31 00:59:09 +00:00
Matt Morehouse 8528b1951c [ASan] Fix >80 character line.
llvm-svn: 366136
2019-07-15 22:07:56 +00:00