On 24 Jan 2019, at 21:25, Dimitry Andric via Release-testers <release-test...@lists.llvm.org> wrote: > > On 24 Jan 2019, at 20:34, Michał Górny <mgo...@gentoo.org> wrote: >> >> On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote: >>> On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers >>> <release-test...@lists.llvm.org> wrote: >>>> >>>> 8.0.0-rc1 was just tagged (from the branch at r351980). ... > Yes, I'm attempting again with this diff applied: > > --- llvm.src/projects/compiler-rt/cmake/config-ix.cmake > +++ llvm.src/projects/compiler-rt/cmake/config-ix.cmake > @@ -118,6 +118,7 @@ check_library_exists(dl dlopen "" COMPIL > check_library_exists(rt shm_open "" COMPILER_RT_HAS_LIBRT) > check_library_exists(m pow "" COMPILER_RT_HAS_LIBM) > check_library_exists(pthread pthread_create "" COMPILER_RT_HAS_LIBPTHREAD) > +check_library_exists(execinfo backtrace "" COMPILER_RT_HAS_LIBEXECINFO) > > # Look for terminfo library, used in unittests that depend on LLVMSupport. > if(LLVM_ENABLE_TERMINFO) > --- llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt > +++ llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt > @@ -71,13 +71,14 @@ if (NOT APPLE) > endforeach() > > # We also add the actual libraries to link as dependencies. > - list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport > -lLLVMTestingSupport) > + list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport > -lLLVMDemangle -lLLVMTestingSupport) > endif() > > append_list_if(COMPILER_RT_HAS_LIBM -lm XRAY_UNITTEST_LINK_FLAGS) > append_list_if(COMPILER_RT_HAS_LIBRT -lrt XRAY_UNITTEST_LINK_FLAGS) > append_list_if(COMPILER_RT_HAS_LIBDL -ldl XRAY_UNITTEST_LINK_FLAGS) > append_list_if(COMPILER_RT_HAS_LIBPTHREAD -pthread XRAY_UNITTEST_LINK_FLAGS) > + append_list_if(COMPILER_RT_HAS_LIBEXECINFO -lexecinfo > XRAY_UNITTEST_LINK_FLAGS) > endif() > > macro(add_xray_unittest testname)
Meanwhile, this diff was applied, but I had little time to look at the tests again. As I mentioned in my previous email, I saw many tests failing with an Asan:DEADLYSIGNAL error, which kept on endlessly repeating, until my log files filled up. This is specifically happening during the dynamic ASan tests, e.g. Asan-x86_64-calls-Dynamic-Test and Asan-x86_64-inline-Dynamic-Test. Running these in gdb shows that it gets into an endless recursion: Starting program: /home/dim/obj/llvm-trunk-r352660/projects/compiler-rt/lib/asan/tests/dynamic/Asan-x86_64-inline-Dynamic-Test Program received signal SIGSEGV, Segmentation fault. 0x000000080097bff1 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 408 reinterpret_cast<AsanThreadContext *>(AsanTSDGet()); (gdb) bt #0 0x000000080097bff1 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #1 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #2 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #3 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #4 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #5 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #6 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #7 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #8 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #9 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #10 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #11 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #12 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #13 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #14 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #15 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 [...goes on until gdb crashes :)...] The __tls_get_addr interceptor in sanitizer_common_interceptors.inc has a comment block which may indicate where the root cause lies: 5096 // If you see any crashes around this functions, there are 2 known issues with 5097 // it: 1. __tls_get_addr can be called with mis-aligned stack due to: 5098 // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 5099 // 2. It can be called recursively if sanitizer code uses __tls_get_addr 5100 // to access thread local variables (it should not happen normally, 5101 // because sanitizers use initial-exec tls model). 5102 INTERCEPTOR(void *, __tls_get_addr, void *arg) { 5103 void *ctx; 5104 COMMON_INTERCEPTOR_ENTER(ctx, __tls_get_addr, arg); It looks like case 2 is happening here. On FreeBSD and NetBSD, there is a special implementation in lib/asan/asan_posix.cc for AsanTSD functions: 43 #if SANITIZER_NETBSD || SANITIZER_FREEBSD 44 // Thread Static Data cannot be used in early init on NetBSD and FreeBSD. 45 // Reuse the Asan TSD API for compatibility with existing code 46 // with an alternative implementation. 47 48 static void (*tsd_destructor)(void *tsd) = nullptr; [...] 67 void *AsanTSDGet() { 68 CHECK(tsd_destructor); 69 return key.key; 70 } Since 'key' is a thread_local variable, the compiler inserts a call to __tls_get_addr: _ZN6__asan10AsanTSDGetEv: # @_ZN6__asan10AsanTSDGetEv .Lfunc_begin4: .loc 2 66 0 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:66:0 .cfi_startproc # %bb.0: .loc 2 67 142 prologue_end # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67:142 pushq %rax .cfi_def_cfa_offset 16 cmpq $0, _ZN6__asanL14tsd_destructorE(%rip) .loc 2 67 117 is_stmt 0 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67:117 je .LBB4_4 # %bb.1: .loc 2 68 10 is_stmt 1 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:10 leaq __tls_guard@TLSLD(%rip), %rdi callq __tls_get_addr@PLT movq %rax, %rcx movb __tls_guard@DTPOFF(%rcx), %cl .Ltmp8: .file 4 "asan_posix.cc" .loc 4 0 0 is_stmt 0 # asan_posix.cc:0:0 testb %cl, %cl je .LBB4_2 .Ltmp9: .LBB4_3: # %_ZTWN6__asanL3keyE.exit .loc 2 68 14 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:14 movq _ZN6__asanL3keyE@GOTTPOFF(%rip), %rax movq %fs:0, %rcx movq (%rcx,%rax), %rax .loc 2 68 3 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:3 popq %rcx retq The first call to AsanTSDGet is from within AsanInitInternal(), via OnMap() and GetCurrentThreadStats(): #0 AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67 #1 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #2 0x0000000800979fc6 in GetCurrentThreadStats () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_stats.cc:117 #3 0x00000008008f43ad in OnMap () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_allocator.cc:190 #4 MapWithCallbackOrDie () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_primary64.h:647 #5 Init () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_primary64.h:83 #6 0x00000008008f23cc in InitLinkerInitialized () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_combined.h:37 #7 InitLinkerInitialized () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_allocator.cc:281 #8 0x00000008009781cc in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:470 #9 0x000000080094a644 in __interceptor_readlink () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6897 #10 0x0000000801532bbc in malloc_conf_init () at jemalloc_jemalloc.c:917 #11 malloc_init_hard_a0_locked () at jemalloc_jemalloc.c:1285 #12 0x0000000801532518 in malloc_init_hard () at jemalloc_jemalloc.c:1521 #13 malloc_init () at jemalloc_jemalloc.c:221 #14 jemalloc_constructor () at jemalloc_jemalloc.c:3285 #15 0x00000008008600eb in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2677 #16 0x000000080085ef3c in _rtld (sp=<optimized out>, exit_proc=0x7fffffffe5c0, objp=0x7fffffffe5c8) at /usr/src/libexec/rtld-elf/rtld.c:744 #17 0x000000080085d019 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39 The second call is still within AsanInitInternal(), but via CreateMainThread() and SetCurrentThread(): #0 AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67 #1 0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432 #2 0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280 #3 0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496 [...] The third call is the start of the endless recursion: #0 AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67 #1 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #2 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #3 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #4 0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432 #5 0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280 #6 0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496 [...] and continuing: #0 AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67 #1 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #2 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #3 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #4 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #5 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #6 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #7 0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432 #8 0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280 #9 0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496 [...] I'm not entirely sure when this behavior changed, since I seem to remember that it did work properly during the 7.0.0 and 7.0.1 release testing. So I will have to bisect. But if anybody has a clue where the endless recursion was introduced, or even better, how to fix it, please let us know. -Dimitry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
