[llvm-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged (original) (raw)

Dimitry Andric via llvm-dev llvm-dev at lists.llvm.org
Sat Feb 2 10:59:06 PST 2019

[trimming some lists since this otherwise gets binned as moderation material]

On 2 Feb 2019, at 15:04, Dimitry Andric <dimitry at andric.com> wrote: 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 @@ checklibraryexists(dl dlopen "" COMPIL checklibraryexists(rt shmopen "" COMPILERRTHASLIBRT) checklibraryexists(m pow "" COMPILERRTHASLIBM) checklibraryexists(pthread pthreadcreate "" COMPILERRTHASLIBPTHREAD) +checklibraryexists(execinfo backtrace "" COMPILERRTHASLIBEXECINFO) # Look for terminfo library, used in unittests that depend on LLVMSupport. if(LLVMENABLETERMINFO) --- 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 XRAYUNITTESTLINKFLAGS -lLLVMXRay -lLLVMSupport -lLLVMTestingSupport) + list(APPEND XRAYUNITTESTLINKFLAGS -lLLVMXRay -lLLVMSupport -lLLVMDemangle -lLLVMTestingSupport) endif() appendlistif(COMPILERRTHASLIBM -lm XRAYUNITTESTLINKFLAGS) appendlistif(COMPILERRTHASLIBRT -lrt XRAYUNITTESTLINKFLAGS) appendlistif(COMPILERRTHASLIBDL -ldl XRAYUNITTESTLINKFLAGS) appendlistif(COMPILERRTHASLIBPTHREAD -pthread XRAYUNITTESTLINKFLAGS) + appendlistif(COMPILERRTHASLIBEXECINFO -lexecinfo XRAYUNITTESTLINKFLAGS) endif() macro(addxrayunittest 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-x8664-calls-Dynamic-Test and Asan-x8664-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-x8664-inline-Dynamic-Test Program received signal SIGSEGV, Segmentation fault. _0x000000080097bff1 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 408 reinterpretcast<AsanThreadContext *>(AsanTSDGet()); (gdb) bt _#0 0x000000080097bff1 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 _#1 0x00000008009408b0 in interceptor_tlsgetaddr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:5107 #2 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68 _#3 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 _#4 0x00000008009408b0 in interceptor_tlsgetaddr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:5107 #5 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68 _#6 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 _#7 0x00000008009408b0 in interceptor_tlsgetaddr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:5107 #8 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68 _#9 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 _#10 0x00000008009408b0 in interceptor_tlsgetaddr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:5107 #11 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68 _#12 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 _#13 0x00000008009408b0 in interceptor_tlsgetaddr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:5107 #14 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68 _#15 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 [...goes on until gdb crashes :)...] _The tlsgetaddr interceptor in sanitizercommoninterceptors.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. tlsgetaddr can be called with mis-aligned stack due to: 5098 // https://gcc.gnu.org/bugzilla/showbug.cgi?id=58066 _5099 // 2. It can be called recursively if sanitizer code uses tlsgetaddr 5100 // to access thread local variables (it should not happen normally, 5101 // because sanitizers use initial-exec tls model). _5102 INTERCEPTOR(void *, tlsgetaddr, void *arg) { 5103 void *ctx; _5104 COMMONINTERCEPTORENTER(ctx, tlsgetaddr, arg); It looks like case 2 is happening here. On FreeBSD and NetBSD, there is a special implementation in lib/asan/asanposix.cc for AsanTSD functions: 43 #if SANITIZERNETBSD || SANITIZERFREEBSD 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 (*tsddestructor)(void *tsd) = nullptr; [...] 67 void *AsanTSDGet() { 68 CHECK(tsddestructor); 69 return key.key; 70 } _Since 'key' is a threadlocal variable, the compiler inserts a call to tlsgetaddr: ZN6_asan10AsanTSDGetEv: # @ZN6_asan10AsanTSDGetEv .Lfuncbegin4: .loc 2 66 0 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:66:0 .cfistartproc # %bb.0: .loc 2 67 142 prologueend # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:67:142 pushq %rax .cfidefcfaoffset 16 cmpq $0, ZN6_asanL14tsddestructorE(%rip) .loc 2 67 117 isstmt 0 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:67:117 je .LBB44 # %bb.1: .loc 2 68 10 isstmt 1 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68:10 leaq _tlsguard at TLSLD(%rip), %rdi callq _tlsgetaddr at PLT movq %rax, %rcx movb _tlsguard at DTPOFF(%rcx), %cl .Ltmp8: .file 4 "asanposix.cc" .loc 4 0 0 isstmt 0 # asanposix.cc:0:0 testb %cl, %cl je .LBB42 .Ltmp9: .LBB43: # %ZTWN6_asanL3keyE.exit .loc 2 68 14 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.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/asanposix.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/asanposix.cc:67 _#1 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 #2 0x0000000800979fc6 in GetCurrentThreadStats () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanstats.cc:117 #3 0x00000008008f43ad in OnMap () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanallocator.cc:190 #4 MapWithCallbackOrDie () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizerallocatorprimary64.h:647 #5 Init () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizerallocatorprimary64.h:83 #6 0x00000008008f23cc in InitLinkerInitialized () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizerallocatorcombined.h:37 #7 InitLinkerInitialized () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanallocator.cc:281 #8 0x00000008009781cc in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanrtl.cc:470 _#9 0x000000080094a644 in interceptorreadlink () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:6897 #10 0x0000000801532bbc in mallocconfinit () at jemallocjemalloc.c:917 #11 mallocinitharda0locked () at jemallocjemalloc.c:1285 #12 0x0000000801532518 in mallocinithard () at jemallocjemalloc.c:1521 #13 mallocinit () at jemallocjemalloc.c:221 #14 jemallocconstructor () at jemallocjemalloc.c:3285 #15 0x00000008008600eb in objlistcallinit (list=, lockstate=) at /usr/src/libexec/rtld-elf/rtld.c:2677 #16 0x000000080085ef3c in rtld (sp=, exitproc=0x7fffffffe5c0, objp=0x7fffffffe5c8) at /usr/src/libexec/rtld-elf/rtld.c:744 #17 0x000000080085d019 in .rtldstart () at /usr/src/libexec/rtld-elf/amd64/rtldstart.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/asanposix.cc:67 #1 0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:432 _#2 0x000000080097b80f in asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:280 #3 0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanrtl.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/asanposix.cc:67 _#1 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 _#2 0x00000008009408b0 in interceptor_tlsgetaddr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:5107 #3 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68 #4 0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:432 _#5 0x000000080097b80f in asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:280 #6 0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanrtl.cc:496 [...] and continuing: #0 AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:67 _#1 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 _#2 0x00000008009408b0 in interceptor_tlsgetaddr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:5107 #3 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68 _#4 0x000000080097bff6 in asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:408 _#5 0x00000008009408b0 in interceptor_tlsgetaddr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizercommon/sanitizercommoninterceptors.inc:5107 #6 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanposix.cc:68 #7 0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:432 _#8 0x000000080097b80f in asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanthread.cc:280 #9 0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asanrtl.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.

It turns out this recursion was introduced by https://reviews.llvm.org/rL349619 ("Reimplement Thread Static Data ASan routines with TLS"). I was apparently subscribed to the review, but I seems to have totally missed it.

Trying the tree just before that revision, e.g. at r349618, also doesn't lead to success, since there it gets into an endless loop between internal_sysctlbyname() and __interceptor_sysctlbyname(), when a call to sysctlbyname() is intercepted during thread initialization:

#0 __sanitizer::internal_sysctlbyname(char const*, void*, unsigned long*, void const*, unsigned long) () at /home/dim/src/llvm/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:783 #1 0x00000008013e61a9 in init_private () at /usr/src/lib/libthr/thread/thr_init.c:478 #2 _libpthread_init (curthread=0x0) at /usr/src/lib/libthr/thread/thr_init.c:331 #3 0x00000008013df342 in _thr_check_init () at /usr/src/lib/libthr/thread/thr_private.h:927 #4 _pthread_key_create (key=0x801211a44 <__asan::tsd_key>, destructor=0x80095cc10 <__asan::PlatformTSDDtor(void*)>) at /usr/src/lib/libthr/thread/thr_spec.c:62 #5 0x000000080095cb43 in __asan::AsanTSDInit(void ()(void)) () at /home/dim/src/llvm/llvm-project/compiler-rt/lib/asan/asan_posix.cc:48 #6 0x0000000800961005 in AsanInitInternal () at /home/dim/src/llvm/llvm-project/compiler-rt/lib/asan/asan_rtl.cc:453 #7 0x0000000800944864 in __interceptor_readlink () at /home/dim/src/llvm/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6880 #8 0x000000080151bbbc in malloc_conf_init () at jemalloc_jemalloc.c:917 #9 malloc_init_hard_a0_locked () at jemalloc_jemalloc.c:1285 #10 0x000000080151b518 in malloc_init_hard () at jemalloc_jemalloc.c:1521 #11 malloc_init () at jemalloc_jemalloc.c:221 #12 jemalloc_constructor () at jemalloc_jemalloc.c:3285 #13 0x000000080085e0eb in objlist_call_init (list=, lockstate=) at /usr/src/libexec/rtld-elf/rtld.c:2677 #14 0x000000080085cf3c in _rtld (sp=, exit_proc=0x7fffffffe5a0, objp=0x7fffffffe5a8) at /usr/src/libexec/rtld-elf/rtld.c:744 #15 0x000000080085b019 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39

Apparently this was also broken somewhere in the past. I don't believe dynamic ASan has worked correctly on FreeBSD for some time...

-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/520f1aad/attachment.sig>

More information about the llvm-dev mailing list