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

[Kostya Serebryany via llvm-dev]

BTW, this is very similar to https://github.com/google/sanitizers/issues/20
(fixed long ago),
apparently we need to add another check to gvn, similar to the one we
already have.
Or figure out why this one does not work...

in lib/Analysis/MemoryDependenceAnalysis.cpp:
 346     if (LIOffs + NewLoadByteSize > MemLocEnd &&
 347         LI->getParent()->getParent()->hasFnAttribute(
 348             Attribute::SanitizeAddress))
 349       // We will be reading past the location accessed by the original
program.
 350       // While this is safe in a regular build, Address Safety
analysis tools
 351       // may start reporting false warnings. So, don't do widening.
 352       return 0;



On Mon, Nov 16, 2015 at 4:59 PM, Kostya Serebryany <kcc at google.com> wrote:

> 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/224d8a9c/attachment.html>