<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2 May 2016, at 11:48, Dmitry Vyukov <<a href="mailto:dvyukov@google.com" class="">dvyukov@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Thu, Apr 28, 2016 at 11:26 AM, Kuba Brecka via llvm-commits<br class=""><<a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class="">Author: kuba.brecka<br class="">Date: Thu Apr 28 04:26:30 2016<br class="">New Revision: 267864<br class=""><br class="">URL: <a href="http://llvm.org/viewvc/llvm-project?rev=267864&view=rev" class="">http://llvm.org/viewvc/llvm-project?rev=267864&view=rev</a><br class="">Log:<br class="">[tsan] Fix Darwin GCD support after separation of Processor and ThreadState<br class=""><br class="">Recent TSan changes (r267678) which factor out parts of ThreadState into a Processor structure broke worker threads on OS X. This fixes it by properly calling ProcCreate for GCD worker threads and by replacing some CHECKs with RAW_CHECK in early process initialization. CHECK() in TSan calls the allocator, which requires a valid Processor.<br class=""><br class=""><br class="">Modified:<br class=""> compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc<br class=""> compiler-rt/trunk/lib/tsan/rtl/tsan_platform_mac.cc<br class=""><br class="">Modified: compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc<br class="">URL: <a href="http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc?rev=267864&r1=267863&r2=267864&view=diff" class="">http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc?rev=267864&r1=267863&r2=267864&view=diff</a><br class="">==============================================================================<br class="">--- compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc (original)<br class="">+++ compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc Thu Apr 28 04:26:30 2016<br class="">@@ -602,7 +602,7 @@ void MaybeReexec() {<br class=""> // wrappers work. If it is not, set DYLD_INSERT_LIBRARIES and re-exec<br class=""> // ourselves.<br class=""> Dl_info info;<br class="">- CHECK(dladdr((void*)((uptr)&__sanitizer_report_error_summary), &info));<br class="">+ RAW_CHECK(dladdr((void*)((uptr)&__sanitizer_report_error_summary), &info));<br class=""> char *dyld_insert_libraries =<br class=""> const_cast<char*>(GetEnv(kDyldInsertLibraries));<br class=""> uptr old_env_len = dyld_insert_libraries ?<br class="">@@ -647,7 +647,7 @@ void MaybeReexec() {<br class=""> "environment variable and re-execute itself, but execv() failed, "<br class=""> "possibly because of sandbox restrictions. Make sure to launch the "<br class=""> "executable with:\n%s=%s\n", kDyldInsertLibraries, new_env);<br class="">- CHECK("execv failed" && 0);<br class="">+ RAW_CHECK("execv failed" && 0);<br class=""> }<br class=""><br class=""> // Verify that interceptors really work. We'll use dlsym to locate<br class="">@@ -655,14 +655,14 @@ void MaybeReexec() {<br class=""> // "wrap_pthread_create" within our own dylib.<br class=""> Dl_info info_pthread_create;<br class=""> void *dlopen_addr = dlsym(RTLD_DEFAULT, "pthread_create");<br class="">- CHECK(dladdr(dlopen_addr, &info_pthread_create));<br class="">+ RAW_CHECK(dladdr(dlopen_addr, &info_pthread_create));<br class=""> if (internal_strcmp(info.dli_fname, info_pthread_create.dli_fname) != 0) {<br class=""> Report(<br class=""> "ERROR: Interceptors are not working. This may be because %s is "<br class=""> "loaded too late (e.g. via dlopen). Please launch the executable "<br class=""> "with:\n%s=%s\n",<br class=""> SanitizerToolName, kDyldInsertLibraries, info.dli_fname);<br class="">- CHECK("interceptors not installed" && 0);<br class="">+ RAW_CHECK("interceptors not installed" && 0);<br class=""> }<br class=""><br class=""> if (!lib_is_in_env)<br class="">@@ -677,7 +677,7 @@ void MaybeReexec() {<br class=""> // sign and the '\0' char.<br class=""> char *new_env = (char*)allocator_for_env.Allocate(<br class=""> old_env_len + 2 + env_name_len);<br class="">- CHECK(new_env);<br class="">+ RAW_CHECK(new_env);<br class=""> internal_memset(new_env, '\0', old_env_len + 2 + env_name_len);<br class=""> internal_strncpy(new_env, kDyldInsertLibraries, env_name_len);<br class=""> new_env[env_name_len] = '=';<br class=""><br class="">Modified: compiler-rt/trunk/lib/tsan/rtl/tsan_platform_mac.cc<br class="">URL: <a href="http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_platform_mac.cc?rev=267864&r1=267863&r2=267864&view=diff" class="">http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_platform_mac.cc?rev=267864&r1=267863&r2=267864&view=diff</a><br class="">==============================================================================<br class="">--- compiler-rt/trunk/lib/tsan/rtl/tsan_platform_mac.cc (original)<br class="">+++ compiler-rt/trunk/lib/tsan/rtl/tsan_platform_mac.cc Thu Apr 28 04:26:30 2016<br class="">@@ -135,10 +135,12 @@ static void my_pthread_introspection_hoo<br class=""> if (event == PTHREAD_INTROSPECTION_THREAD_CREATE) {<br class=""> if (thread == pthread_self()) {<br class=""> // The current thread is a newly created GCD worker thread.<br class="">+ ThreadState *thr = cur_thread();<br class="">+ Processor *proc = ProcCreate();<br class=""></blockquote><br class="">Any signal that arrives between cur_thread() and ProcWire will be<br class="">delayed, right?<br class=""></div></div></blockquote><div><br class=""></div><div>I think signals are actually <i class="">not</i> disabled during early new thread state, and this bug was already present before this patch :(</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I think you also need to explicitly ProcDestroy the proc.<br class=""></div></div></blockquote><div><br class=""></div><div>Let me double check, but I think DestroyThreadState is called for both regular and worker threads, which will destroy the Processor.</div><div><br class=""></div><div>Kuba</div></div><br class=""></body></html>