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.