[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