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: [PATCH 01/10] Initial import of asan from the Google branch into trunk


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 <jakub@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]