There is can be a situation when vptr is not initializing
by constructor of the object, and has a junk data which should
be properly checked, because c++ standard says:
"if default constructor is not specified
16 (7.3) no initialization is performed."
Patch by Denis Khalikov!
Differential Revision: https://reviews.llvm.org/D33712
llvm-svn: 304437
This patch addresses https://github.com/google/sanitizers/issues/774. When we
fork a multi-threaded process it's possible to deadlock if some thread acquired
StackDepot or allocator internal lock just before fork. In this case the lock
will never be released in child process causing deadlock on following memory alloc/dealloc
routine. While calling alloc/dealloc routines after multi-threaded fork is not allowed,
most of modern allocators (Glibc, tcmalloc, jemalloc) are actually fork safe. Let's do the same
for sanitizers except TSan that has complex locking rules.
Differential Revision: https://reviews.llvm.org/D33325
llvm-svn: 304285
Summary:
D33521 addressed a memory ordering issue in BlockingMutex, which seems
to be the cause of a flakiness of a few ASan tests on PowerPC.
Reviewers: eugenis
Subscribers: kubamracek, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33611
llvm-svn: 304045
The test was meant for Darwin anyway, so I'm not even sure it's supposed
to run on Linux. If it was, then we need time to investigate, but since
the test is new, there's no point in reverting the whole patch because
of it.
llvm-svn: 304010
Summary:
Currently we are not enforcing the success of `pthread_once`, and
`pthread_setspecific`. Errors could lead to harder to debug issues later in
the thread's life. This adds checks for a 0 return value for both.
If `pthread_setspecific` fails in the teardown path, opt for an immediate
teardown as opposed to a fatal failure.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33555
llvm-svn: 303998
Summary:
D33521 addressed a memory ordering issue in BlockingMutex, which seems
to be the cause of a flakiness of a few ASan tests on PowerPC.
Reviewers: eugenis
Subscribers: kubamracek, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33569
llvm-svn: 303995
Summary:
allow_user_segv_handler had confusing name did not allow to control behavior for
signals separately.
Reviewers: eugenis, alekseyshl, kcc
Subscribers: llvm-commits, dberris, kubamracek
Differential Revision: https://reviews.llvm.org/D33371
llvm-svn: 303941
Summary:
This required for any users who call exit() after creating
thread-specific data, as tls destructors are only called when
pthread_exit() or pthread_cancel() are used. This should also
match tls behavior on linux.
Getting the base address of the tls section is straightforward,
as it's stored as a section offset in %gs. The size is a bit trickier
to work out, as there doesn't appear to be any official documentation
or source code referring to it. The size used in this patch was determined
by taking the difference between the base address and the address of the
subsequent memory region returned by vm_region_recurse_64, which was
1024 * sizeof(uptr) on all threads except the main thread, where it was
larger. Since the section must be the same size on all of the threads,
1024 * sizeof(uptr) seemed to be a reasonable size to use, barring
a more programtic way to get the size.
1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX
is 512 on darwin, so pthread keys will fit inside the region while
leaving space for other tls data. A larger size would overflow the
memory region returned by vm_region_recurse_64, and a smaller size
wouldn't leave room for all the pthread keys. In addition, the
stress test added here passes, which means that we are scanning at
least the full set of possible pthread keys, and probably
the full tls section.
Reviewers: alekseyshl, kubamracek
Subscribers: krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D33215
llvm-svn: 303887
The existing implementation ran CHECKs to assert that the thread state
was stored inside the tls. However, the mac implementation of tsan doesn't
store the thread state in tls, so these checks fail once darwin tls support
is added to the sanitizers. Only run these checks on platforms where
the thread state is expected to be contained in the tls.
llvm-svn: 303886
Summary:
Apparently Windows's `UnmapOrDie` doesn't support partial unmapping. Which
makes the new region allocation technique not Windows compliant.
Reviewers: alekseyshl, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33554
llvm-svn: 303883
Summary:
Currently, AllocateRegion has a tendency to fragment memory: it allocates
`2*kRegionSize`, and if the memory is aligned, will unmap `kRegionSize` bytes,
thus creating a hole, which can't itself be reused for another region. This
is exacerbated by the fact that if 2 regions get allocated one after another
without any `mmap` in between, the second will be aligned due to mappings
generally being contiguous.
An idea, suggested by @alekseyshl, to prevent such a behavior is to have a
stash of regions: if the `2*kRegionSize` allocation is properly aligned, split
it in two, and stash the second part to be returned next time a region is
requested.
At this point, I thought about a couple of ways to implement this:
- either an `IntrusiveList` of regions candidates, storing `next` at the
begining of the region;
- a small array of regions candidates existing in the Primary.
While the second option is more constrained in terms of size, it offers several
advantages:
- security wise, a pointer in a region candidate could be overflowed into, and
abused when popping an element;
- we do not dirty the first page of the region by storing something in it;
- unless several threads request regions simultaneously from different size
classes, the stash rarely goes above 1 entry.
I am not certain about the Windows impact of this change, as `sanitizer_win.cc`
has its own version of MmapAlignedOrDie, maybe someone could chime in on this.
MmapAlignedOrDie is effectively unused after this change and could be removed
at a later point. I didn't notice any sizeable performance gain, even though we
are saving a few `mmap`/`munmap` syscalls.
Reviewers: alekseyshl, kcc, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33454
llvm-svn: 303879
Summary:
Dmitry, seeking your expertise. I believe, the proper way to implement
Lock/Unlock here would be to use acquire/release semantics. Am I missing
something?
Reviewers: dvyukov
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33521
llvm-svn: 303869
Summary:
In FreeBSD we needed to add generic implementations for `__bswapdi2` and
`__bswapsi2`, since gcc 6.x for mips is emitting calls to these. See:
https://reviews.freebsd.org/D10838 and https://reviews.freebsd.org/rS318601
The actual mips code generated for these generic C versions is pretty
OK, as can be seen in the (FreeBSD) review.
I checked over gcc sources, and it seems that it can emit these calls on
more architectures, so maybe it's best to simply always add them to the
compiler-rt builtins library.
Reviewers: howard.hinnant, compnerd, petarj, emaste
Reviewed By: compnerd, emaste
Subscribers: mgorny, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D33516
llvm-svn: 303866
This test case occassionally fails when run on powerpc64 be.
asan/TestCases/Posix/halt_on_error-torture.cc
The failure causes false problem reports to be sent to developers whose
code had nothing to do with the failures. Reactivate it when the real
problem is fixed.
This could also be related to the same problems as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, ManyThreadsTest,
and several others that do not run reliably on powerpc.
llvm-svn: 303864
Summary:
This flags is not covered by tests on Windows and looks like it's implemented
incorrectly. Switching its default breaks some tests.
Taking into account that related handle_segv flag is not supported on Windows
it's safer to remove it until we commit to support it.
Reviewers: eugenis, zturner, rnk
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33471
llvm-svn: 303728
Summary: We are going to make it tri-state and remove allow_user_segv_handler.
Reviewers: eugenis, alekseys, kcc
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D33159
llvm-svn: 303464
Summary:
The LINKEDIT section is very large and is read-only. Scanning this
section caused LSan on darwin to be very slow. When only writable sections
are scanned for global pointers, performance improved by a factor of about 25x.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33322
llvm-svn: 303422
Summary:
After discussing the current defaults with a couple of parties, the consensus
is that they are too high. 1Mb of quarantine has about a 4Mb impact on PSS, so
memory usage goes up quickly.
This is obviously configurable, but the default value should be more
"approachable", so both the global size and the thread local size are 1/4 of
what they used to be.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33321
llvm-svn: 303380
The sanitizer library unit tests for libc can get a different definition
of 'struct stat' to what the sanitizer library is built with for certain
targets.
For MIPS the size element of 'struct stat' is after a macro guarded
explicit padding element.
This patch resolves any possible inconsistency by adding the same
_FILE_OFFSET_BITS=64 and _LARGE_SOURCE with the same
conditions as the sanitizer library to the build flags for the unit tests.
This resolves a recurring build failure on the MIPS buildbots due to
'struct stat' defintion differences.
Reviewers: slthakur
Differential Revision: https://reviews.llvm.org/D33131
llvm-svn: 303350
Vedant Kumar