[Release-testers] [8.0.0 Release] rc1 has been tagged

Dimitry Andric via Release-testers release-testers 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 @@ 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.

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=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2677
#14 0x000000080085cf3c in _rtld (sp=<optimized out>, 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/release-testers/attachments/20190202/520f1aad/attachment.sig>


More information about the Release-testers mailing list