POSIX states that "It shall be safe to destroy an initialized condition
variable upon which no threads are currently blocked", and later clarifies
"A condition variable can be destroyed immediately after all the threads
that are blocked on it are awakened) (in examples section). Tsan reported
such destruction as a data race.
Fixes https://llvm.org/bugs/show_bug.cgi?id=23616
Reviewed in http://reviews.llvm.org/D10693
llvm-svn: 241082
which caches the executable name upon the first invocation.
This is necessary because Google Chrome (and potentially other programs)
restrict the access to /proc/self/exe on linux.
This change should fix https://code.google.com/p/chromium/issues/detail?id=502974
llvm-svn: 240960
The new suppression type is called "race_top" and is matched only against top frame in report stacks.
This is required for situations when we want to suppress a race in a "thread pool" or "event loop" implementation.
If we simply use "race:ThreadPool::Execute" suppression, that can suppress everything in the program.
Reviewed in http://reviews.llvm.org/D10686
llvm-svn: 240949
Summary:
On PPC64, half the msan tests fail with an infinite recursion through
GetStackTrace like this:
#0 __msan::GetStackTrace
#1 __msan_memcpy
#2 ?? () from /lib64/libgcc_s.so.1
#3 ?? () from /lib64/libgcc_s.so.1
#4 _Unwind_Backtrace
#5 __sanitizer::BufferedStackTrace::SlowUnwindStack
#6 __sanitizer::BufferedStackTrace::Unwind
#7 __msan::GetStackTrace
#8 __interceptor_calloc
#9 _dl_allocate_tls
#10 pthread_create@@GLIBC_2.17
#11 __interceptor_pthread_create
#12 main
The problem is that we call _Unwind_Backtrace to get a stack trace; but
_Unwind_Backtrace calls memcpy, which we intercept and try to get
another stack trace.
This patch fixes it in __msan_memcpy by skipping the stack trace if
IsInSymbolizer(). This works because GetStackTrace already creates a
SymbolizerScope to "block reports from our interceptors during
_Unwind_Backtrace".
Reviewers: samsonov, wschmidt, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10762
llvm-svn: 240878
We were unsetting DYLD_ROOT_PATH before calling atos on Darwin in order to
address it not working for symbolicating 32 bit binaries. (atos essentiall
tries to respawn as a 32 bit binary and it's disallowed to respawn if
DYLD_ROOT_PATH is set ... ) However, processes rely on having DYLD_ROOT_PATH
set under certain conditions, so this is not the right fix. In particular, this
always crashes when running ASanified process under the debugger in Xcode with
iOS simulator, which is a very important workflow for us to support.
This patch reverts the unsetting of the DYLD_ROOT_PATH. The correct fix to the
misbehavior on 32-bit binaries should happen inside atos.
http://reviews.llvm.org/D10722
llvm-svn: 240724
Summary:
This fixes test/msan/Linux/syscalls.cc, and should also fix the ppc64
sanitizer buildbots which are currently failing in
"make check-sanitizer".
Reviewers: samsonov, wschmidt, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10734
llvm-svn: 240692
Summary:
On PPC64 if you disable ASLR (or run under gdb) you're likely to see
mmap returning a mapping right at the end of the application address
space region. This caused SetShadow to call MEM_TO_SHADOW() on the
last+1 address in the region, which seems wrong to me; how can
MEM_TO_SHADOW() distinguish this from the first address in the following
region?
Fixed by only calling MEM_TO_SHADOW() once, on the start address.
Reviewers: samsonov, wschmidt, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10735
llvm-svn: 240690
Previously tsan modelled dup2(oldfd, newfd) as write on newfd.
We hit several cases where the write lead to false positives:
1. Some software dups a closed pipe in place of a socket before closing
the socket (to prevent races actually).
2. Some daemons dup /dev/null in place of stdin/stdout.
On the other hand we have not seen cases when write here catches real bugs.
So model dup2 as read on newfd instead.
llvm-svn: 240687
Summary:
This patch adds basic memory sanitizer support for PPC64. PR23219.
I have further patches ready to enable it in LLVM and Clang, and to fix
most of the many failing tests in check-msan.
Reviewers: kcc, willschm, samsonov, wschmidt, eugenis
Reviewed By: eugenis
Subscribers: wschmidt, llvm-commits
Differential Revision: http://reviews.llvm.org/D10648
llvm-svn: 240623
Summary:
This patch implements step 1 from
https://llvm.org/bugs/show_bug.cgi?id=23539#c10
I'd appreciate if you could test it on Mac OS and verify that parts of UBSan
runtime that reference C++ ABI symbols are properly excluded, and fix ASan/UBSan
builds.
Test Plan: regression test suite
Reviewers: thakis, hans
Subscribers: llvm-commits, zaks.anna, kubabrecka
Differential Revision: http://reviews.llvm.org/D10621
llvm-svn: 240617
Summary: _Unwind_Backtrace is not available on iOS, so we should ifdef out the posix implementations of BufferedStackTrace::SlowUnwindStack and BufferedStackTrace::SlowUnwindStackWithContext on iOS.
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10696
llvm-svn: 240586
We see false reports between dlopen and dl_iterate_phdr.
This happens because tsan does not see dynamic linker
internal synchronization. Unpoison module names
in dl_iterate_phdr callback.
llvm-svn: 240576
This happens only in corner cases, but we observed this on a real app.
See the test for description of the exact scenario that lead to unbounded memory consumption.
llvm-svn: 240535
This patch clarifies the TODO note at the top of safestack.cc and brings
it more in sync with what we (the CPI team) actually plan to work on in
the future.
Patch by Volodymyr Kuznetsov!
Differential Revision: http://reviews.llvm.org/D10600
llvm-svn: 240473
Summary:
This is one of many changes needed for compiler-rt to get it building on iOS.
Darwin doesn't have _Unwind_VRS_Get, instead use _Unwind_GetIP directly.
Note: this change does not enable building for iOS, as there are more changes to come.
Reviewers: kubabrecka, bogner, samsonov
Reviewed By: samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D10516
llvm-svn: 240470
Summary:
This is one of many changes needed for compiler-rt to get it building on iOS.
This change ifdefs out headers and functionality that aren't available on iOS, and adds support for iOS and the iOS simulator to as an.
Note: this change does not enable building for iOS, as there are more changes to come.
Reviewers: glider, kubabrecka, bogner, samsonov
Reviewed By: samsonov
Subscribers: samsonov, zaks.anna, llvm-commits
Differential Revision: http://reviews.llvm.org/D10515
llvm-svn: 240469
Summary:
This is one of many changes needed for compiler-rt to get it building on iOS.
This change ifdefs out headers and functionality that aren't available on iOS.
Note: this change does not enable building for iOS, as there are more changes to come.
Reviewers: glider, kubabrecka, bogner, samsonov
Reviewed By: samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D10514
llvm-svn: 240468
Summary:
This is one of many changes needed for compiler-rt to get it building on iOS.
This change does the following:
- Don't include crt_externs on iOS (it isn't available)
- Support ARM thread state objects
Note: this change does not enable building for iOS, as there are more changes to come.
Reviewers: glider, kubabrecka, bogner, samsonov
Reviewed By: samsonov
Subscribers: samsonov, aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D10510
llvm-svn: 240467
Summary:
This patch fixes incorrect truncation when the input wider value is
exactly 2^dstBits. For that value, the overflow to infinity is not
correctly handled. The fix is to replace a strict '>' with '>='.
Currently,
__truncdfsf2(340282366900000000000000000000000000000.0) returns infinity
__truncdfsf2(340282366920938463463374607431768211456.0) returns 0
__truncdfsf2(400000000000000000000000000000000000000.0) returns infinity
Likewise, __truncdfhf2 and __truncsfhf2 (and consequently gnu_f2h_ieee)
are discontinuous at 65536.0.
This patch adds tests for all three cases, along with adding a missing
header include to fp_test.h.
Reviewers: joerg, ab, srhines
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10594
llvm-svn: 240450
I have no idea how to directly test that as it depends on a particular
(micro-)architecure of the host processor.
Combined with llvm's r240339 this should fix issues people might have
be seeing intermitently on Darwin haswell machines (the symbolizer
would use the wrong slice of the binary, thus potentially resolving
to the wrong symbol).
llvm-svn: 240379
Summary:
Use CMake's cmake_parse_arguments() instead.
It's called in a slightly different way, but supports all our use cases.
It's in CMake 2.8.8, which is our minimum supported version.
CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc):
http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments
Since I was already changing these calls, I changed ARCH and LIB into
ARCHS and LIBS to make it more clear that they're lists of arguments.
Reviewers: eugenis, samsonov, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10529
llvm-svn: 240120
Meta shadow is compressing and we don't flush it,
so it makes sense to mark it as NOHUGEPAGE to not over-allocate memory.
On one program it reduces memory consumption from 5GB to 2.5GB.
llvm-svn: 240028
This change makes cmake fail to even run on Darwin with errors
evaluating "$<TARGET_OBJECTS:RTInterception.x86_64>".
This reverts r239955
llvm-svn: 239985
This patch adds runtime support for the Safe Stack protection to compiler-rt
(see http://reviews.llvm.org/D6094 for the detailed description of the
Safe Stack).
This patch is our implementation of the safe stack on top of compiler-rt. The
patch adds basic runtime support for the safe stack to compiler-rt that
manages unsafe stack allocation/deallocation for each thread.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6096
llvm-svn: 239763
Summary:
This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library.
The goal of this is to try to push platform handling as low in the utility functions as possible.
Reviewers: rnk, samsonov
Reviewed By: rnk, samsonov
Subscribers: rnk, rsmith, llvm-commits
Differential Revision: http://reviews.llvm.org/D10250
llvm-svn: 239498
/code/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:971:8: error: address of function 'dl_iterate_phdr' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
if (!dl_iterate_phdr)
~^~~~~~~~~~~~~~~
/code/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:971:8: note: prefix with the address-of operator to silence this warning
if (!dl_iterate_phdr)
^
&
llvm-svn: 239321
Summary:
With this patch, we have a flag to toggle displaying source locations in
the regular style:
file:line:column
or Visual Studio style:
file(line,column)
This way, they get picked up on the Visual Studio output window and one
can double-click them to get to that file location.
Reviewers: samsonov, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10113
llvm-svn: 239000
Dmitry Vyukov