This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 11:56 AM, Ramana Radhakrishnan
<ramana.radhakrishnan@arm.com> wrote:
> On 05/23/14 08:50, Yury Gribov wrote:
>>
>>   > On ARM the asan tests have always been a random generator of PASS /
>>   > FAIL on qemu despite efforts to "nobble" qemu for /proc/self/maps
>>   > outputs.
>>
>> This should improve once upstream Asan sets up an ARM build bot. This
>> has been discussed recently but noone has yet volunteered to do the
>> server installation and setup.
>>
>>   > After the merge I see these new failures instead
>>
>> A pity that gcc-testresults does not report mismatched lines.
>>
>> My guess is this is caused by some unwinding failures when reporting
>> heap allocations:
>>
>
> Ok, so we need to fix that if there is a bug.

Yep.

>
>
>> $ grep -R 'allocated by thread' ./gcc/testsuite/c-c++-common/asan -l
>> ./gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c
>> ./gcc/testsuite/c-c++-common/asan/heap-overflow-1.c
>> ./gcc/testsuite/c-c++-common/asan/use-after-free-1.c
>>
>
> This is what I see from the log and all failures look identical.
>
> ==14627==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x41a007fa
> at pc 0x88c4 bp 0xbebd0084 sp 0xbebd007c
> READ of size 1 at 0x41a007fa thread T0
>     #0 0x88c3 in main
> /work/gcc/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c:21
>     #1 0x40626631 in __libc_start_main
> (/lib/arm-linux-gnueabihf/libc.so.6+0x17631)
>
> 0x41a007fa is located 0 bytes to the right of 10-byte region
> [0x41a007f0,0x41a007fa)
> allocated by thread T0 here:
>     #0 0x400cd587 in __interceptor_malloc
> /work/gcc/libsanitizer/asan/asan_malloc_linux.cc:73

Looks indeed like wrong unwind, similar to what has been recently
discussed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140519/218239.html

>
> SUMMARY: AddressSanitizer: heap-buffer-overflow
> /work/gcc/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c:21 main
> Shadow bytes around the buggy address:
>   0x283400a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x283400b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x283400c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x283400d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x283400e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> =>0x283400f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00[02]
>   0x28340100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x28340110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x28340120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x28340130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x28340140: 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
>   ASan internal:           fe
> ==14627==ABORTING
>
>
>
>
>> -Y
>>
>
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]