2019-08-01 22:01:30 +08:00
|
|
|
//=-- lsan_common_mac.cpp -------------------------------------------------===//
|
2017-02-14 05:03:15 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-02-14 05:03:15 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file is a part of LeakSanitizer.
|
|
|
|
// Implementation of common leak checking functionality. Darwin-specific code.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "sanitizer_common/sanitizer_platform.h"
|
2018-11-14 04:19:38 +08:00
|
|
|
#include "sanitizer_common/sanitizer_libc.h"
|
2017-02-14 05:03:15 +08:00
|
|
|
#include "lsan_common.h"
|
|
|
|
|
|
|
|
#if CAN_SANITIZE_LEAKS && SANITIZER_MAC
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
|
2017-03-27 22:07:50 +08:00
|
|
|
#include "sanitizer_common/sanitizer_allocator_internal.h"
|
|
|
|
#include "lsan_allocator.h"
|
|
|
|
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
#include <pthread.h>
|
|
|
|
|
2017-04-17 22:07:06 +08:00
|
|
|
#include <mach/mach.h>
|
|
|
|
|
[Sanitizers, LSan, Darwin] Allow for lack of VM_MEMORY_OS_ALLOC_ONCE
Summary:
Some time ago, the sanitizers as of r315899 were imported into gcc mainline. This broke
bootstrap on Darwin 10 and 11, as reported in GCC PR sanitizer/82824
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824) due to the unconditional use
of VM_MEMORY_OS_ALLOC_ONCE. This was only introduced in Darwin 13/Mac OS X 10.9.
The use of the macro was introduced in r300450.
I couldn't find any statement which Darwin versions are supposed to be supported by
LLVM, but the trivial patch to use the macro only if present allowed the gcc bootstrap
to finish.
So far, I haven't tried building llvm/compiler-rt on Darwin 11. Maybe the patch is
simple enough to go in nonetheless.
Committing on behalf of ro.
Reviewers: glider, fjricci, kcc, kuba, kubamracek, george.karpenkov
Reviewed By: fjricci
Subscribers: #sanitizers, zaks.anna, srhines, dberris, kubamracek, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D39888
llvm-svn: 322437
2018-01-13 22:43:49 +08:00
|
|
|
// Only introduced in Mac OS X 10.9.
|
|
|
|
#ifdef VM_MEMORY_OS_ALLOC_ONCE
|
|
|
|
static const int kSanitizerVmMemoryOsAllocOnce = VM_MEMORY_OS_ALLOC_ONCE;
|
|
|
|
#else
|
|
|
|
static const int kSanitizerVmMemoryOsAllocOnce = 73;
|
|
|
|
#endif
|
|
|
|
|
2017-02-14 05:03:15 +08:00
|
|
|
namespace __lsan {
|
|
|
|
|
2017-02-17 11:23:07 +08:00
|
|
|
typedef struct {
|
|
|
|
int disable_counter;
|
|
|
|
u32 current_thread_id;
|
2017-03-27 22:07:50 +08:00
|
|
|
AllocatorCache cache;
|
2017-02-17 11:23:07 +08:00
|
|
|
} thread_local_data_t;
|
|
|
|
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
static pthread_key_t key;
|
|
|
|
static pthread_once_t key_once = PTHREAD_ONCE_INIT;
|
|
|
|
|
2017-04-12 03:57:12 +08:00
|
|
|
// The main thread destructor requires the current thread id,
|
|
|
|
// so we can't destroy it until it's been used and reset to invalid tid
|
|
|
|
void restore_tid_data(void *ptr) {
|
|
|
|
thread_local_data_t *data = (thread_local_data_t *)ptr;
|
|
|
|
if (data->current_thread_id != kInvalidTid)
|
|
|
|
pthread_setspecific(key, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void make_tls_key() {
|
|
|
|
CHECK_EQ(pthread_key_create(&key, restore_tid_data), 0);
|
|
|
|
}
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
|
2017-03-29 05:56:45 +08:00
|
|
|
static thread_local_data_t *get_tls_val(bool alloc) {
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
pthread_once(&key_once, make_tls_key);
|
|
|
|
|
2017-02-17 11:23:07 +08:00
|
|
|
thread_local_data_t *ptr = (thread_local_data_t *)pthread_getspecific(key);
|
2017-03-29 05:56:45 +08:00
|
|
|
if (ptr == NULL && alloc) {
|
2017-02-17 11:23:07 +08:00
|
|
|
ptr = (thread_local_data_t *)InternalAlloc(sizeof(*ptr));
|
|
|
|
ptr->disable_counter = 0;
|
|
|
|
ptr->current_thread_id = kInvalidTid;
|
2017-03-27 22:07:50 +08:00
|
|
|
ptr->cache = AllocatorCache();
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
pthread_setspecific(key, ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
2017-03-29 05:56:45 +08:00
|
|
|
bool DisabledInThisThread() {
|
|
|
|
thread_local_data_t *data = get_tls_val(false);
|
|
|
|
return data ? data->disable_counter > 0 : false;
|
|
|
|
}
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
|
2017-03-29 05:56:45 +08:00
|
|
|
void DisableInThisThread() { ++get_tls_val(true)->disable_counter; }
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
|
|
|
|
void EnableInThisThread() {
|
2017-03-29 05:56:45 +08:00
|
|
|
int *disable_counter = &get_tls_val(true)->disable_counter;
|
Use pthreads to manage thread-local storage on darwin for leak sanitizer
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
2017-02-14 06:20:07 +08:00
|
|
|
if (*disable_counter == 0) {
|
|
|
|
DisableCounterUnderflow();
|
|
|
|
}
|
|
|
|
--*disable_counter;
|
|
|
|
}
|
|
|
|
|
2017-04-12 03:57:12 +08:00
|
|
|
u32 GetCurrentThread() {
|
|
|
|
thread_local_data_t *data = get_tls_val(false);
|
2017-06-20 03:21:31 +08:00
|
|
|
return data ? data->current_thread_id : kInvalidTid;
|
2017-04-12 03:57:12 +08:00
|
|
|
}
|
2017-02-17 11:23:07 +08:00
|
|
|
|
2017-03-29 05:56:45 +08:00
|
|
|
void SetCurrentThread(u32 tid) { get_tls_val(true)->current_thread_id = tid; }
|
2017-02-17 11:23:07 +08:00
|
|
|
|
2017-03-29 05:56:45 +08:00
|
|
|
AllocatorCache *GetAllocatorCache() { return &get_tls_val(true)->cache; }
|
2017-03-27 22:07:50 +08:00
|
|
|
|
2017-04-19 22:00:35 +08:00
|
|
|
LoadedModule *GetLinker() { return nullptr; }
|
|
|
|
|
2017-03-30 05:49:13 +08:00
|
|
|
// Required on Linux for initialization of TLS behavior, but should not be
|
|
|
|
// required on Darwin.
|
Implement tls scanning for darwin LSan
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
2017-05-26 01:41:13 +08:00
|
|
|
void InitializePlatformSpecificModules() {}
|
2017-02-14 05:03:15 +08:00
|
|
|
|
2017-07-26 02:16:58 +08:00
|
|
|
// Sections which can't contain contain global pointers. This list errs on the
|
|
|
|
// side of caution to avoid false positives, at the expense of performance.
|
|
|
|
//
|
|
|
|
// Other potentially safe sections include:
|
|
|
|
// __all_image_info, __crash_info, __const, __got, __interpose, __objc_msg_break
|
|
|
|
//
|
|
|
|
// Sections which definitely cannot be included here are:
|
|
|
|
// __objc_data, __objc_const, __data, __bss, __common, __thread_data,
|
|
|
|
// __thread_bss, __thread_vars, __objc_opt_rw, __objc_opt_ptrs
|
|
|
|
static const char *kSkippedSecNames[] = {
|
|
|
|
"__cfstring", "__la_symbol_ptr", "__mod_init_func",
|
|
|
|
"__mod_term_func", "__nl_symbol_ptr", "__objc_classlist",
|
|
|
|
"__objc_classrefs", "__objc_imageinfo", "__objc_nlclslist",
|
|
|
|
"__objc_protolist", "__objc_selrefs", "__objc_superrefs"};
|
|
|
|
|
2017-02-14 05:03:15 +08:00
|
|
|
// Scans global variables for heap pointers.
|
|
|
|
void ProcessGlobalRegions(Frontier *frontier) {
|
2018-11-14 04:19:38 +08:00
|
|
|
for (auto name : kSkippedSecNames)
|
2018-11-14 06:17:16 +08:00
|
|
|
CHECK(internal_strnlen(name, kMaxSegName + 1) <= kMaxSegName);
|
2017-07-26 02:16:58 +08:00
|
|
|
|
2017-04-14 02:40:19 +08:00
|
|
|
MemoryMappingLayout memory_mapping(false);
|
2018-05-07 13:56:24 +08:00
|
|
|
InternalMmapVector<LoadedModule> modules;
|
|
|
|
modules.reserve(128);
|
2017-04-14 02:40:19 +08:00
|
|
|
memory_mapping.DumpListOfModules(&modules);
|
|
|
|
for (uptr i = 0; i < modules.size(); ++i) {
|
|
|
|
// Even when global scanning is disabled, we still need to scan
|
|
|
|
// system libraries for stashed pointers
|
|
|
|
if (!flags()->use_globals && modules[i].instrumented()) continue;
|
|
|
|
|
|
|
|
for (const __sanitizer::LoadedModule::AddressRange &range :
|
|
|
|
modules[i].ranges()) {
|
2017-07-19 07:51:44 +08:00
|
|
|
// Sections storing global variables are writable and non-executable
|
|
|
|
if (range.executable || !range.writable) continue;
|
|
|
|
|
2017-07-26 02:16:58 +08:00
|
|
|
for (auto name : kSkippedSecNames) {
|
|
|
|
if (!internal_strcmp(range.name, name)) continue;
|
|
|
|
}
|
|
|
|
|
2017-07-19 07:51:44 +08:00
|
|
|
ScanGlobalRange(range.beg, range.end, frontier);
|
2017-04-14 02:40:19 +08:00
|
|
|
}
|
|
|
|
}
|
2017-02-14 05:03:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ProcessPlatformSpecificAllocations(Frontier *frontier) {
|
2017-04-17 22:07:06 +08:00
|
|
|
unsigned depth = 1;
|
|
|
|
vm_size_t size = 0;
|
|
|
|
vm_address_t address = 0;
|
|
|
|
kern_return_t err = KERN_SUCCESS;
|
|
|
|
mach_msg_type_number_t count = VM_REGION_SUBMAP_INFO_COUNT_64;
|
|
|
|
|
2017-04-20 05:11:08 +08:00
|
|
|
InternalMmapVector<RootRegion> const *root_regions = GetRootRegions();
|
|
|
|
|
2017-04-17 22:07:06 +08:00
|
|
|
while (err == KERN_SUCCESS) {
|
|
|
|
struct vm_region_submap_info_64 info;
|
2018-08-24 06:55:58 +08:00
|
|
|
err = vm_region_recurse_64(mach_task_self(), &address, &size, &depth,
|
2017-04-17 22:07:06 +08:00
|
|
|
(vm_region_info_t)&info, &count);
|
2017-04-20 05:11:08 +08:00
|
|
|
|
|
|
|
uptr end_address = address + size;
|
|
|
|
|
|
|
|
// libxpc stashes some pointers in the Kernel Alloc Once page,
|
|
|
|
// make sure not to report those as leaks.
|
[Sanitizers, LSan, Darwin] Allow for lack of VM_MEMORY_OS_ALLOC_ONCE
Summary:
Some time ago, the sanitizers as of r315899 were imported into gcc mainline. This broke
bootstrap on Darwin 10 and 11, as reported in GCC PR sanitizer/82824
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824) due to the unconditional use
of VM_MEMORY_OS_ALLOC_ONCE. This was only introduced in Darwin 13/Mac OS X 10.9.
The use of the macro was introduced in r300450.
I couldn't find any statement which Darwin versions are supposed to be supported by
LLVM, but the trivial patch to use the macro only if present allowed the gcc bootstrap
to finish.
So far, I haven't tried building llvm/compiler-rt on Darwin 11. Maybe the patch is
simple enough to go in nonetheless.
Committing on behalf of ro.
Reviewers: glider, fjricci, kcc, kuba, kubamracek, george.karpenkov
Reviewed By: fjricci
Subscribers: #sanitizers, zaks.anna, srhines, dberris, kubamracek, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D39888
llvm-svn: 322437
2018-01-13 22:43:49 +08:00
|
|
|
if (info.user_tag == kSanitizerVmMemoryOsAllocOnce) {
|
2017-04-20 05:11:08 +08:00
|
|
|
ScanRangeForPointers(address, end_address, frontier, "GLOBAL",
|
|
|
|
kReachable);
|
2017-05-09 22:10:30 +08:00
|
|
|
|
|
|
|
// Recursing over the full memory map is very slow, break out
|
|
|
|
// early if we don't need the full iteration.
|
|
|
|
if (!flags()->use_root_regions || !root_regions->size())
|
|
|
|
break;
|
2017-04-17 22:07:06 +08:00
|
|
|
}
|
2017-04-20 05:11:08 +08:00
|
|
|
|
|
|
|
// This additional root region scan is required on Darwin in order to
|
|
|
|
// detect root regions contained within mmap'd memory regions, because
|
|
|
|
// the Darwin implementation of sanitizer_procmaps traverses images
|
|
|
|
// as loaded by dyld, and not the complete set of all memory regions.
|
|
|
|
//
|
|
|
|
// TODO(fjricci) - remove this once sanitizer_procmaps_mac has the same
|
|
|
|
// behavior as sanitizer_procmaps_linux and traverses all memory regions
|
|
|
|
if (flags()->use_root_regions) {
|
|
|
|
for (uptr i = 0; i < root_regions->size(); i++) {
|
|
|
|
ScanRootRegion(frontier, (*root_regions)[i], address, end_address,
|
2017-07-12 02:54:00 +08:00
|
|
|
info.protection & kProtectionRead);
|
2017-04-20 05:11:08 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
address = end_address;
|
2017-04-17 22:07:06 +08:00
|
|
|
}
|
2017-02-14 05:03:15 +08:00
|
|
|
}
|
|
|
|
|
Don't call exit() from atexit handlers on Darwin
Summary:
Calling exit() from an atexit handler is undefined behavior.
On Linux, it's unavoidable, since we cannot intercept exit (_exit isn't called
if a user program uses return instead of exit()), and I haven't
seen it cause issues regardless.
However, on Darwin, I have a fairly complex internal test that hangs roughly
once in every 300 runs after leak reporting finishes, which is resolved with
this patch, and is presumably due to the undefined behavior (since the Die() is
the only thing that happens after the end of leak reporting).
In addition, this is the way TSan works as well, where an atexit handler+Die()
is used on Linux, and an _exit() interceptor is used on Darwin. I'm not sure if it's
intentionally structured that way in TSan, since TSan sets up the atexit handler and the
_exit() interceptor on both platforms, but I have observed that on Darwin, only the
_exit() interceptor is used, and on Linux the atexit handler is used.
There is some additional related discussion here: https://reviews.llvm.org/D35085
Reviewers: alekseyshl, kubamracek
Subscribers: eugenis, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D35513
llvm-svn: 308353
2017-07-19 04:18:32 +08:00
|
|
|
// On darwin, we can intercept _exit gracefully, and return a failing exit code
|
|
|
|
// if required at that point. Calling Die() here is undefined behavior and
|
|
|
|
// causes rare race conditions.
|
|
|
|
void HandleLeaks() {}
|
|
|
|
|
2020-01-25 08:52:12 +08:00
|
|
|
void LockStuffAndStopTheWorld(StopTheWorldCallback callback,
|
|
|
|
CheckForLeaksParam *argument) {
|
2019-09-20 03:52:57 +08:00
|
|
|
LockThreadRegistry();
|
|
|
|
LockAllocator();
|
2017-04-20 05:11:07 +08:00
|
|
|
StopTheWorld(callback, argument);
|
2019-09-20 03:52:57 +08:00
|
|
|
UnlockAllocator();
|
|
|
|
UnlockThreadRegistry();
|
2017-02-14 05:03:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace __lsan
|
|
|
|
|
|
|
|
#endif // CAN_SANITIZE_LEAKS && SANITIZER_MAC
|