Michał Górny via llvm-dev
2019-Jan-24 19:34 UTC
[llvm-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged
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-testers at lists.llvm.org> wrote: > > > > 8.0.0-rc1 was just tagged (from the branch at r351980). > > > > It took a little longer than planned, but it's looking good. > > > > Please run the test script, share your results, and upload binaries. > > Unfortunately I'm running into a problem with check-all, where it fails to link XRayTest-x86_64-Test: > > [100%] Generating XRayTest-x86_64-Test > /home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)': > Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace' > Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)' > clang-8: error: linker command failed with exit code 1 (use -v to see invocation) > gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1 > gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors. > gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2 > gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors. > gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2 > gmake[1]: Target 'check-all' not remade because of errors. > gmake: *** [Makefile:277: check-all] Error 2 > [Release Phase3] check-all failed > > It appears this is because -lexecinfo is not passed to the link command line, but I'm unsure why this only seems to affect the XRay test. I'm investigating, but if anybody has a cluestick, please hit me. :-) >We've been having similar issue on NetBSD in the past. Long story short, the code around there is not using CMake rules to build stuff but a custom compiler invocation, and therefore it does not inherit library dependencies from CMake. Short-term solution is to figure out what's missing and add it, with appropriate conditionals. Long-term solution (which is probably not suitable for 8.0.0) is to rewrite that whole stuff. Probably could work by creating a custom language for CMake that's like C but uses just-built clang, etc. However, that's just my theory and I'm not 100% sure it'll work or how much work it'd involve. -- Best regards, Michał Górny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190124/aae00497/attachment.sig>
Dimitry Andric via llvm-dev
2019-Jan-24 20:25 UTC
[llvm-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged
On 24 Jan 2019, at 20:34, Michał Górny <mgorny at 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-testers at lists.llvm.org> wrote: >>> >>> 8.0.0-rc1 was just tagged (from the branch at r351980). >>> >>> It took a little longer than planned, but it's looking good. >>> >>> Please run the test script, share your results, and upload binaries. >> >> Unfortunately I'm running into a problem with check-all, where it fails to link XRayTest-x86_64-Test: >> >> [100%] Generating XRayTest-x86_64-Test >> /home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)': >> Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace' >> Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)' >> clang-8: error: linker command failed with exit code 1 (use -v to see invocation) >> gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1 >> gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors. >> gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2 >> gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors. >> gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2 >> gmake[1]: Target 'check-all' not remade because of errors. >> gmake: *** [Makefile:277: check-all] Error 2 >> [Release Phase3] check-all failed >> >> It appears this is because -lexecinfo is not passed to the link command line, but I'm unsure why this only seems to affect the XRay test. I'm investigating, but if anybody has a cluestick, please hit me. :-) >> > > We've been having similar issue on NetBSD in the past. Long story > short, the code around there is not using CMake rules to build stuff but > a custom compiler invocation, and therefore it does not inherit library > dependencies from CMake. > > Short-term solution is to figure out what's missing and add it, with > appropriate conditionals.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) Now the next problem is a Asan:DEADLYSIGNAL which keeps on repeating endlessly. :-) -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190124/e056be52/attachment.sig>
Dimitry Andric via llvm-dev
2019-Feb-02 14:04 UTC
[llvm-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged
On 24 Jan 2019, at 21:25, Dimitry Andric via Release-testers <release-testers at lists.llvm.org> wrote:> > On 24 Jan 2019, at 20:34, Michał Górny <mgorny at 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-testers at 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 at TLSLD(%rip), %rdi callq __tls_get_addr at PLT movq %rax, %rcx movb __tls_guard at 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190202/b8647f85/attachment.sig>