> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || > 0x7fff8000(0xffffffffbc0) == 0x10007fff7bc0
Access is within HighShadow, which should be writable. What does /proc/$PID/maps say? On Fri, Jan 15, 2021 at 12:33 PM Jeffrey Walton <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/address-sanitizer/8cb8a33b-57ef-4811-a13a-457f1676ff9en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAFKCwrh5XzKXdwBr66oQ0yjgxOw3%3D%2BuZ8-BGb4%3DwLJSX%3DvTcBg%40mail.gmail.com.
