Thanks again Evgeniy,

> Try running with ASAN_OPTIONS=verbosity=2,debug=1, it should print the 
memory layout.

And here is the run with ASAN_OPTIONS:

(gdb) shell reset
(gdb) set env ASAN_OPTIONS=verbosity=2,debug=1
(gdb) r
...
Starting program: /home/jwalton/ok2delete-asan/bin/bash 
==3933371==info->dlpi_name =     info->dlpi_addr = 0x555555554000
==3933371==info->dlpi_name = linux-vdso.so.1    info->dlpi_addr = 
0x7ffff7fce000
==3933371==info->dlpi_name = /usr/lib/x86_64-linux-gnu/libasan.so.5    
info->dlpi_addr = 0x7ffff7597000
==3933371==AddressSanitizer: libc interceptors initialized
|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem    ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap  ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow  ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem     ||
MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 
0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
thread_local_quarantine_size_kb=1024K
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
==3933371==Installed the sigaction for signal 11
==3933371==Installed the sigaction for signal 7
==3933371==Installed the sigaction for signal 8
==3933371==SetCurrentThread: 0x7ffff7576000 for thread 0x7ffff71b1bc0
==3933371==T0: stack [0x7fffff7ff000,0x7ffffffff000) size 0x800000; 
local=0x7fffffffdf04
==3933371==Using libbacktrace symbolizer.
==3933371==AddressSanitizer Init done
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
==3933371==info->dlpi_name =     info->dlpi_addr = 0x555555554000
==3933371==info->dlpi_name = linux-vdso.so.1    info->dlpi_addr = 
0x7ffff7fce000
==3933371==info->dlpi_name = /usr/lib/x86_64-linux-gnu/libasan.so.5    
info->dlpi_addr = 0x7ffff7597000

Program received signal SIGSEGV, Segmentation fault.
0x000055555578cb83 in internal_malloc (n=n@entry=0x20, file=file@entry=0x0, 
    line=line@entry=0x0, flags=<optimized out>) at malloc.c:820
820    in malloc.c
(gdb) 

Jeff

On Friday, January 15, 2021 at 2:57:53 PM UTC-5 Evgeniy Stepanov wrote:

> 0x7fff8000(0xffffffffbc0) looks fine - it's a shadow address for ~near top 
> of the main thread stack. Perhaps ASan did not initialize in time? What's 
> the backtrace of the crash? Try a breakpoint on __asan_init. Try running 
> with ASAN_OPTIONS=verbosity=2,debug=1, it should print the memory layout.
>
>
> On Fri, Jan 15, 2021 at 11:48 AM Jeffrey Walton <[email protected]> wrote:
>
>> Hi Everyone,
>>
>> I'm testing an Asan instrumented build of Bash. Bash and all dependencies 
>> have been instrumented. I'm working on Ubuntu 20.04 x86_64 fully patched. 
>> It has gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0.
>>
>> All of the executables and shared objects were built with  
>> CFLAGS/CXXFLAGS of -fsanitize=address and -fno-omit-frame-pointer. LDFLAGS 
>> includes -fno-lto. (I tried both with and without LTO).
>>
>> Bash is crashing in startup code. It looks like Asan is trying to setup a 
>> red zone:
>>
>>    shr    $0x3,%r15
>>    ===> movl   $0xf1f1f1f1,0x7fff8000(%r15)
>>         movl   $0xf3f3f304,0x7fff8004(%r15)
>>
>> r15 is 0xffffffffbc0. The effective address of 0x7fff8000(0xffffffffbc0) 
>> does seem to be a bit sideways.
>>
>> Does anyone know where to go from here?
>>
>> -----
>>
>> (gdb) r
>> ...
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x000055555578cb83 in internal_malloc (n=n@entry=0x20, 
>> file=file@entry=0x0, 
>>     line=line@entry=0x0, flags=<optimized out>) at malloc.c:820
>> 820    in malloc.c
>> (gdb) disass
>> Dump of assembler code for function internal_malloc:
>>    0x000055555578cb20 <+0>:    push   %rbp
>>    0x000055555578cb21 <+1>:    mov    %rsp,%rbp
>>    0x000055555578cb24 <+4>:    push   %r15
>>    0x000055555578cb26 <+6>:    lea    -0x90(%rbp),%rcx
>>    0x000055555578cb2d <+13>:    push   %r14
>>    0x000055555578cb2f <+15>:    mov    %rsi,%r14
>>    0x000055555578cb32 <+18>:    push   %r13
>>    0x000055555578cb34 <+20>:    mov    %rdi,%r13
>>    0x000055555578cb37 <+23>:    push   %r12
>>    0x000055555578cb39 <+25>:    push   %rbx
>>    0x000055555578cb3a <+26>:    sub    $0xa8,%rsp
>>    0x000055555578cb41 <+33>:    mov    0x6d2e8(%rip),%rax        # 
>> 0x5555557f9e30
>>    0x000055555578cb48 <+40>:    mov    %edx,-0xa0(%rbp)
>>    0x000055555578cb4e <+46>:    mov    (%rax),%edx
>>    0x000055555578cb50 <+48>:    mov    %rcx,-0x98(%rbp)
>>    0x000055555578cb57 <+55>:    test   %edx,%edx
>>    0x000055555578cb59 <+57>:    jne    0x55555578d7cf 
>> <internal_malloc+3247>
>>    0x000055555578cb5f <+63>:    lea    0x4856a(%rip),%rax        # 
>> 0x5555557d50d0
>>    0x000055555578cb66 <+70>:    mov    %rax,0x8(%rcx)
>>    0x000055555578cb6a <+74>:    lea    -0x51(%rip),%rax        # 
>> 0x55555578cb20 --Type <RET> for more, q to quit, c to continue without 
>> paging--
>> <internal_malloc>
>>    0x000055555578cb71 <+81>:    movq   $0x41b58ab3,(%rcx)
>>    0x000055555578cb78 <+88>:    mov    %rax,0x10(%rcx)
>>    0x000055555578cb7c <+92>:    mov    %rcx,%r15
>>    0x000055555578cb7f <+95>:    shr    $0x3,%r15
>> => 0x000055555578cb83 <+99>:    movl   $0xf1f1f1f1,0x7fff8000(%r15)
>>    0x000055555578cb8e <+110>:    movl   $0xf3f3f304,0x7fff8004(%r15)
>>    0x000055555578cb99 <+121>:    mov    0xc6261(%rip),%ebx        # 
>> 0x555555852e00 <pagesz>
>>    0x000055555578cb9f <+127>:    lea    0x60(%rcx),%r8
>>    0x000055555578cba3 <+131>:    mov    %fs:0x28,%rax
>>    0x000055555578cbac <+140>:    mov    %rax,-0x38(%rbp)
>>    0x000055555578cbb0 <+144>:    xor    %eax,%eax
>>    0x000055555578cbb2 <+146>:    test   %ebx,%ebx
>>    0x000055555578cbb4 <+148>:    je     0x55555578d3c0 
>> <internal_malloc+2208>
>>    0x000055555578cbba <+154>:    lea    0x23(%r13),%rsi
>>    0x000055555578cbbe <+158>:    sar    %ebx
>>    0x000055555578cbc0 <+160>:    and    $0xfffffffffffffff0,%rsi
>>    0x000055555578cbc4 <+164>:    movslq %ebx,%rbx
>>    0x000055555578cbc7 <+167>:    cmp    %rbx,%rsi
>>    0x000055555578cbca <+170>:    jg     0x55555578d100 
>> <internal_malloc+1504>
>>    0x000055555578cbd0 <+176>:    mov    $0x10,%eax
>>    0x000055555578cbd5 <+181>:    mov    $0x1,%ebx
>>    ...
>>
>> (gdb) info registers
>> rax            0x55555578cb20      0x55555578cb20
>> rbx            0x0                 0x0
>> rcx            0x7fffffffde00      0x7fffffffde00
>> rdx            0x0                 0x0
>> rsi            0x0                 0x0
>> rdi            0x20                0x20
>> rbp            0x7fffffffde90      0x7fffffffde90
>> rsp            0x7fffffffddc0      0x7fffffffddc0
>> r8             0x0                 0x0
>> r9             0x1                 0x1
>> r10            0x7ffff7438b0f      0x7ffff7438b0f
>> r11            0x55555578e5e0      0x55555578e5e0
>> r12            0x20                0x20
>> r13            0x20                0x20
>> r14            0x0                 0x0
>> r15            0xffffffffbc0       0xffffffffbc0
>> rip            0x55555578cb83      0x55555578cb83 <internal_malloc+99>
>> eflags         0x10206             [ PF IF RF ]
>> cs             0x33                0x33
>> ss             0x2b                0x2b
>> ds             0x0                 0x0
>> es             0x0                 0x0
>> fs             0x0                 0x0
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/address-sanitizer/8cb8a33b-57ef-4811-a13a-457f1676ff9en%40googlegroups.com.

Reply via email to