[llvm-dev] Inexplicable ASAN report. Code generation bug?

[Kostya Serebryany via llvm-dev]

Confirmed.


A smaller repro:

typedef union {
  short q;
  struct {
    short x;
    short y;
    int for_alignment;
  } w;
} U;
char *buf = new char[2];
int main() {
  buf[0] = buf[1] = 0x0;
  U *u = (U *)buf;
  return  u->q == 0 ? 0 : u->w.y;
}


With O2 asan produces false positive and with -O1/-O0 it does not.
One more case where an optimization is hostile to asan...
Looking.



On Sat, Nov 14, 2015 at 9:09 AM, Greg Stark <stark at mit.edu> wrote:

> On Thu, Nov 12, 2015 at 8:42 PM, Kostya Serebryany <kcc at google.com> wrote:
> > 2 questions:
> > - Do you see this with the fresh llvm trunk?
> > - Can you prepare a minimized example?
>
> Pretty recent, I updated a couple days ago. I tried to minimize the
> attached but at the same time I didn't want to lose too many unions
> and casts in case it didn't trigger any more.
>
> $ clang -fsanitize=address  -Wall numeric-asan-test.c
> $ ./a.out
> VARSIZE 6
> NDIGITS 0
> WEIGHT 0
> SIGN 0
> DSCALE 0
> $ clang -fsanitize=address -O2  -Wall numeric-asan-test.c
> $ ./a.out
> VARSIZE 6
> =================================================================
> ==19982==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x60200000eff4 at pc 0x0000004d4986 bp 0x7ffe14e2cb90 sp
> 0x7ffe14e2cb88
> READ of size 4 at 0x60200000eff4 thread T0
>     #0 0x4d4985 in main (/home/stark/src/a.out+0x4d4985)
>     #1 0x7f6360f40b44 in __libc_start_main
> /tmp/buildd/glibc-2.19/csu/libc-start.c:287
>     #2 0x41a935 in _start (/home/stark/src/a.out+0x41a935)
>
> 0x60200000eff6 is located 0 bytes to the right of 6-byte region
> [0x60200000eff0,0x60200000eff6)
> allocated by thread T0 here:
>     #0 0x4abceb in __interceptor_malloc
>
> /home/stark/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
>     #1 0x4d479e in main (/home/stark/src/a.out+0x4d479e)
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow
> (/home/stark/src/a.out+0x4d4985) in main
> Shadow bytes around the buggy address:
>   0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> =>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa[06]fa
>   0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:           00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:       fa
>   Heap right redzone:      fb
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack partial redzone:   f4
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Container overflow:      fc
>   Array cookie:            ac
>   Intra object redzone:    bb
>   ASan internal:           fe
>   Left alloca redzone:     ca
>   Right alloca redzone:    cb
> ==19982==ABORTING
>
>
>
> --
> greg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151116/d65c5efc/attachment.html>