[PATCH 01/10] Initial import of asan from the Google branch into trunk
Xinliang David Li
davidxl@google.com
Fri Nov 9 16:53:00 GMT 2012
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
More information about the Gcc-patches
mailing list