[llvm-dev] Intermittent lsan failure on aarch64-linux
Adhemerval Zanella via llvm-dev
llvm-dev at lists.llvm.org
Fri May 14 11:24:39 PDT 2021
On 14/05/2021 02:44, Vitaly Buka wrote:
> Probably sched_yield() clobbered x13. Can you disassemble your glibc
> version?
>
> Can you try change the test to
> asm("mov x13, %0\n"
> "mov x14, %0\n"
> "mov x15, %0"
> :
> : "r"(p));
>
> It should be fine to store value in additional registers just in case.
I though about it, but it does not seems to be the case as below (the
system default to bind-now, so no loader resolution in involved here).
I will check if adding the malloc address in extra register will improve,
the main problem is the failure is really intermittent.
(gdb) disas
Dump of assembler code for function registers_thread_func:
0x000000000042dc18 <+0>: sub sp, sp, #0x30
0x000000000042dc1c <+4>: stp x29, x30, [sp, #32]
0x000000000042dc20 <+8>: add x29, sp, #0x20
0x000000000042dc24 <+12>: stur x0, [x29, #-8]
0x000000000042dc28 <+16>: ldur x8, [x29, #-8]
0x000000000042dc2c <+20>: str x8, [sp, #16]
0x000000000042dc30 <+24>: mov w8, #0x539 // #1337
0x000000000042dc34 <+28>: mov w0, w8
0x000000000042dc38 <+32>: bl 0x42bc18 <__interceptor_malloc(__sanitizer::uptr)>
0x000000000042dc3c <+36>: str x0, [sp, #8]
0x000000000042dc40 <+40>: ldr x2, [sp, #8]
0x000000000042dc44 <+44>: adrp x0, 0x437000
0x000000000042dc48 <+48>: add x0, x0, #0x4a4
0x000000000042dc4c <+52>: mov w1, #0x1 // #1
0x000000000042dc50 <+56>: str w1, [sp, #4]
0x000000000042dc54 <+60>: bl 0x42dab8 <_Z13print_addressPKciz>
0x000000000042dc58 <+64>: adrp x8, 0x454000 <_ZN11__sanitizer11report_fileE+7680>
0x000000000042dc5c <+68>: ldr x0, [x8, #2752]
0x000000000042dc60 <+72>: bl 0x4039c0 <fflush at plt>
0x000000000042dc64 <+76>: ldr w0, [sp, #4]
0x000000000042dc68 <+80>: ldr x8, [sp, #8]
0x000000000042dc6c <+84>: mov x13, x8
0x000000000042dc70 <+88>: ldr x1, [sp, #16]
0x000000000042dc74 <+92>: bl 0x42dd20 <__aarch64_ldeor4_acq_rel>
0x000000000042dc78 <+96>: b 0x42dc7c <registers_thread_func+100>
=> 0x000000000042dc7c <+100>: bl 0x403a20 <sched_yield at plt>
0x000000000042dc80 <+104>: b 0x42dc7c <registers_thread_func+100>
Dump of assembler code for function __aarch64_ldeor4_acq_rel:
=> 0x000000000042dce0 <+0>: bti c
0x000000000042dce4 <+4>: adrp x16, 0xda9000 <_ZZN6__lsan24InitializeThreadRegistryEvE27thread_registry_placeholder>
0x000000000042dce8 <+8>: ldrb w16, [x16, #208]
0x000000000042dcec <+12>: cbz w16, 0x42dcf8 <__aarch64_ldeor4_acq_rel+24>
0x000000000042dcf0 <+16>: ldeoral w0, w0, [x1]
0x000000000042dcf4 <+20>: ret
0x000000000042dcf8 <+24>: mov w16, w0
0x000000000042dcfc <+28>: ldaxr w0, [x1]
0x000000000042dd00 <+32>: eor w17, w0, w16
0x000000000042dd04 <+36>: stlxr w15, w17, [x1]
0x000000000042dd08 <+40>: cbnz w15, 0x42dcfc <__aarch64_ldeor4_acq_rel+28>
0x000000000042dd0c <+44>: ret
=> 0x403a20 <sched_yield at plt>: adrp x16, 0x452000 <_Unwind_Backtrace at got.plt>
0x403a24 <sched_yield at plt+4>: ldr x17, [x16, #336]
0x403a28 <sched_yield at plt+8>: add x16, x16, #0x150
0x403a2c <sched_yield at plt+12>: br x17
(gdb) x/20i $pc
=> 0xfffff7c065e0 <sched_yield>: mov x8, #0x7c // #124
0xfffff7c065e4 <sched_yield+4>: svc #0x0
0xfffff7c065e8 <sched_yield+8>: cmn x0, #0xfff
0xfffff7c065ec <sched_yield+12>: b.cs 0xfffff7c065f4 <sched_yield+20> // b.hs, b.nlast
0xfffff7c065f0 <sched_yield+16>: ret
0xfffff7c065f4 <sched_yield+20>: b 0xfffff7b6c190 <__GI___syscall_error>
(gdb) disas __GI___syscall_error
Dump of assembler code for function __GI___syscall_error:
0x0000fffff7b6c190 <+0>: adrp x2, 0xfffff7cb4000 <sys_sigabbrev+368>
0x0000fffff7b6c194 <+4>: ldr x2, [x2, #3600]
0x0000fffff7b6c198 <+8>: mrs x3, tpidr_el0
0x0000fffff7b6c19c <+12>: mov x1, x0
0x0000fffff7b6c1a0 <+16>: mov x0, #0xffffffffffffffff // #-1
0x0000fffff7b6c1a4 <+20>: neg w1, w1
0x0000fffff7b6c1a8 <+24>: str w1, [x3, x2]
0x0000fffff7b6c1ac <+28>: ret
> On Thu, 13 May 2021 at 11:45, Adhemerval Zanella via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I am investigating an intermittent failure on aarch64 linux bots related to
>> asan, where the use_registers.cpp sometimes fails. I tried to check if it
>> some related issue on the test itself, but it does seems to do what the
>> code is trying to simulate (an thread with store the address of a leaked
>> allocation on the stack thread).
>>
>> Instrumenting the code to dump some log (log_pointers=1:log_threads=1) the
>> following below (I omitted my local paths). It seems that on some runs
>> 'use_registers=1' is really working as intended.
>>
>> Any idea? It started to show when we moved ours buildbots to newer ubuntu
>> 20.04 (with has a recent glibc 2.31), but I am not sure it is a glibc
>> related issue.
>>
>> ---
>>
>> FAIL: LeakSanitizer-Standalone-aarch64 :: TestCases/use_registers.cpp (289
>> of 80810)
>> ******************** TEST 'LeakSanitizer-Standalone-aarch64 ::
>> TestCases/use_registers.cpp' FAILED ********************
>> Script:
>> --
>> : 'RUN: at line 2';
>> LSAN_BASE="report_objects=1:use_stacks=0:log_pointers=1:log_threads=1"
>> : 'RUN: at line 3'; <build_path>/bin/clang --driver-mode=g++ -O0
>> -gline-tables-only -fsanitize=leak -I<src_path>/compiler-rt/test/lsan/../
>> -pthread <src_path>/compiler-rt/test/lsan/TestCases/use_registers.cpp -o
>> <build_path>/projects/compiler-rt/test/lsan/AARCH64LsanConfig/TestCases/Output/use_registers.cpp.tmp
>> : 'RUN: at line 4'; env
>> LSAN_OPTIONS=:detect_leaks=1:$LSAN_BASE:"use_registers=0" not
>> <build_path>/projects/compiler-rt/test/lsan/AARCH64LsanConfig/TestCases/Output/use_registers.cpp.tmp
>> 2>&1 | FileCheck
>> <src_path>/compiler-rt/test/lsan/TestCases/use_registers.cpp
>> : 'RUN: at line 5'; env
>> LSAN_OPTIONS=:detect_leaks=1:$LSAN_BASE:"use_registers=1"
>> <build_path>/projects/compiler-rt/test/lsan/AARCH64LsanConfig/TestCases/Output/use_registers.cpp.tmp
>> 2>&1
>> : 'RUN: at line 6'; env LSAN_OPTIONS=:detect_leaks=1:""
>> <build_path>/projects/compiler-rt/test/lsan/AARCH64LsanConfig/TestCases/Output/use_registers.cpp.tmp
>> 2>&1
>> --
>> Exit Code: 23
>>
>> Command Output (stdout):
>> --
>> Test alloc: 0xffff7d503600
>> ==342105==Ignored: chunk 0xffff7db03e80-0xffff7db03fb0 of size 304.
>> ==342105==Scanning GLOBAL range 0x0000004516f0-0x000000d25e80.
>> ==342105==Scanning GLOBAL range 0x000000da6f00-0x000000da90d8.
>> ==342105==Scanning GLOBAL range 0xffff7fe507d8-0xffff7fe606b0.
>> ==342105==0xffff7fe5d3e8: found 0xffff7e500000 pointing into chunk
>> 0xffff7e500000-0xffff7e511c00 of size 72704.
>> ==342105==Scanning GLOBAL range 0xffff7fc7cd58-0xffff7fc7d078.
>> ==342105==Scanning GLOBAL range 0xffff7fbcbbf8-0xffff7fbd03e8.
>> ==342105==Scanning GLOBAL range 0xffff7fb9fd60-0xffff7fba0330.
>> ==342105==Scanning GLOBAL range 0xffff7fb87d48-0xffff7fb88100.
>> ==342105==Scanning GLOBAL range 0xffff7fb73db8-0xffff7fb74458.
>> ==342105==Scanning GLOBAL range 0xffff7fb478b8-0xffff7fb4fc50.
>> ==342105==Scanning GLOBAL range 0xffff7fe92590-0xffff7fe94200.
>> ==342105==Processing thread 342082.
>> ==342105==Scanning REGISTERS range 0xffff7f875000-0xffff7f875110.
>> ==342105==TLS at 0xffff7f9cd030-0xffff7f9db6b0.
>> ==342105==Scanning TLS range 0xffff7f9cd030-0xffff7f9cd760.
>> ==342105==Scanning TLS range 0xffff7f9daf80-0xffff7f9db6b0.
>> ==342105==Processing thread 342099.
>> ==342105==Scanning REGISTERS range 0xffff7f875000-0xffff7f875110.
>> ==342105==TLS at 0xffff7e4f1980-0xffff7e500000.
>> ==342105==Scanning TLS range 0xffff7e4f1980-0xffff7e4f20b0.
>> ==342105==Scanning TLS range 0xffff7e4ff8d0-0xffff7e500000.
>> ==342105==Scanning HEAP range 0xffff7e500000-0xffff7e511c00.
>> ==342105==Scanning HEAP range 0xffff7db03e80-0xffff7db03fb0.
>> ==342105==Processing platform-specific allocations.
>> ==342105==Scanning leaked chunks.
>> ==342105==Scanning HEAP range 0xffff7d503600-0xffff7d503b39.
>> ==342105==Scanning HEAP range 0xffff7db03e80-0xffff7db03fb0.
>>
>> =================================================================
>> ==342082==ERROR: LeakSanitizer: detected memory leaks
>>
>> Direct leak of 1337 byte(s) in 1 object(s) allocated from:
>> #0 0x42bc20 in malloc
>> <src_path>/compiler-rt/lib/lsan/lsan_interceptors.cpp:56:3
>> #1 0x42dbf8 in registers_thread_func
>> <src_path>/compiler-rt/test/lsan/TestCases/use_registers.cpp:17:13
>> #2 0xffff7fba94f8 in start_thread
>> /build/glibc-iW00TY/glibc-2.31/nptl/pthread_create.c:477:8
>> #3 0xffff7fab1678
>> /build/glibc-iW00TY/glibc-2.31/misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Objects leaked above:
>> 0xffff7d503600 (1337 bytes)
>>
>> SUMMARY: LeakSanitizer: 1337 byte(s) leaked in 1 allocation(s).
>>
>> --
>>
>> ********************
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
More information about the llvm-dev
mailing list