It seems that my one line fix in asan branch (r192605) is not included
in Dodji's patch set.

David


On Fri, Nov 9, 2012 at 5:58 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Fri, Nov 09, 2012 at 02:14:04PM +0100, Tobias Burnus wrote:
>> Dodji Seketeli wrote:
>> >This patch imports the initial state of asan as it was in the
>> >Google branch.
>> >
>> >It provides basic infrastructure for asan to instrument memory
>> >accesses on the heap, at -O3.  Note that it supports neither stack nor
>> >global variable protection.
>>
>> I tried the 01/10 to 10/10 patch series but it doesn't trigger for
>> the following test case:
>>
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> int
>> main() {
>>   int *i;
>>   i = malloc(10*sizeof(*i));
>>   free(i);  /* <<< Free memory. */
>>   i[10] = 5;  /* <<< out of boundary even if not freed. */
>>   printf("%d\n", i[11]);  /* <<< out of boundary even if not freed. */
>>   return 0;
>> }
>>
>> (All of them are reported by Clang.) If I look at the dump (or
>> assembler), I see the call to __asan_init, __asan_report_store4 and
>> __asan_report_load4. However, when running the program ltrace only
>> shows the calls to: __libc_start_main, __asan_init, malloc, free and
>> printf. I haven't debugged why the condition is false [see
>> attachment for the dump].
>
> Can't reproduce that (admittedly with asan SVN branch rather than the
> patchset):
>
> ./xgcc -B ./ -O2 -fasan -o a a.c 
> -Wl,-rpath,/usr/src/gcc-asan/obj/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/
>  \
>                                  -L 
> /usr/src/gcc-asan/obj/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/
> ./a
> =================================================================
> ==20614== ERROR: AddressSanitizer heap-use-after-free on address
> 0x7f7d8245afec at pc 0x4006f8 bp 0x7fff9beda4c0 sp 0x7fff9beda4b8
> READ of size 4 at 0x7f7d8245afec thread T0
>     #0 0x4006f7 (/usr/src/gcc-asan/obj/gcc/a+0x4006f7)
> 0x7f7d8245afec is located 4 bytes to the right of 40-byte region
> [0x7f7d8245afc0,0x7f7d8245afe8)
> freed by thread T0 here:
>     #0 0x7f7d82796585
>     
> #(/usr/src/gcc-asan/obj/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.so.0.0.0+0xf585)
>     #1 0x4006b5 (/usr/src/gcc-asan/obj/gcc/a+0x4006b5)
> previously allocated by thread T0 here:
>     #0 0x7f7d82796645
>     
> #(/usr/src/gcc-asan/obj/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.so.0.0.0+0xf645)
>     #1 0x4006aa (/usr/src/gcc-asan/obj/gcc/a+0x4006aa)
> Shadow byte and word:
>   0x1fefb048b5fd: fd
>   0x1fefb048b5f8: fd fd fd fd fd fd fd fd
> More shadow bytes:
>   0x1fefb048b5d8: fa fa fa fa fa fa fa fa
>   0x1fefb048b5e0: fa fa fa fa fa fa fa fa
>   0x1fefb048b5e8: fa fa fa fa fa fa fa fa
>   0x1fefb048b5f0: fa fa fa fa fa fa fa fa
> =>0x1fefb048b5f8: fd fd fd fd fd fd fd fd
>   0x1fefb048b600: fa fa fa fa fa fa fa fa
>   0x1fefb048b608: fa fa fa fa fa fa fa fa
>   0x1fefb048b610: fa fa fa fa fa fa fa fa
>   0x1fefb048b618: fa fa fa fa fa fa fa fa
> Stats: 0M malloced (0M for red zones) by 1 calls
> Stats: 0M realloced by 0 calls
> Stats: 0M freed by 1 calls
> Stats: 0M really freed by 0 calls
> Stats: 0M (128 full pages) mmaped in 1 calls
>   mmaps   by size class: 7:4095;
>   mallocs by size class: 7:1;
>   frees   by size class: 7:1;
>   rfrees  by size class:
> Stats: malloc large: 0 small slow: 1
> ==20614== ABORTING
>
>         Jakub

Reply via email to