https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84208
Bug ID: 84208 Summary: fsanitize-address-use-after-scope Not working for ARM Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: akhilesh.k at samsung dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Dear All I am working On gcc 6.2.1 i wan't to verify use-after-scope feature for ARM Since 6.2.1 don't support this feature I migrated this feature form 7.1 to 6.2.1. After Migration i observed that this Feature is working for My X86 but bot working one ARM target. Test results on ARM (gcc 6.2.1) bash-3.2# ./out_of_scope bash-3.2# Test results on X86 (gcc 6.2.1) bash-3.2# ./out_of_scope ================================================================= ==45124==ERROR: AddressSanitizer: stack-use-after-scope on address 0xffe5b560 at pc 0x080486b5 bp 0xffe5b508 sp 0xffe5b4fc WRITE of size 1 at 0xffe5b560 thread T0 #0 0x80486b4 in main /home/abuild/rpmbuild/BUILDROOT/test2.c:10 #1 0xf70123d7 in __libc_start_main (/lib/libc.so.6+0x183d7) #2 0x8048500 (/home/abuild/rpmbuild/BUILDROOT/out_of_scope+0x8048500) Address 0xffe5b560 is located in stack of thread T0 at offset 32 in frame #0 0x80485e9 in main /home/abuild/rpmbuild/BUILDROOT/test2.c:3 This frame has 1 object(s): [32, 33) 'my_char' <== Memory access at offset 32 is inside this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: AddressSanitizer stack-use-after-scope /home/abuild/rpmbuild/BUILDROOT/test2.c:10 in main Shadow bytes around the buggy address: 0x3ffcb650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x3ffcb6a0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1[f8]f4 f4 f4 0x3ffcb6b0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 ==45124==ABORTING Query 1. As per my analysis i think This feature is architecture in dependent (Please correct me if i am wrong) Thanks Akhilesh