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

Dimitry Andric via lldb-dev lldb-dev at lists.llvm.org
Sat Feb 2 06:04:01 PST 2019


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/lldb-dev/attachments/20190202/b8647f85/attachment.sig>


More information about the lldb-dev mailing list