http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543
--- Comment #7 from Yury Gribov <y.gribov at samsung dot com> --- Created attachment 30946 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30946&action=edit Standalone repro Dodji, It has just occured to me that you probably want an executable repro with nice runtime error. Here is the first try (mainly a harness around the previous repro). The testcase firstly runs function bad() which fails to unpoison frame shadow. It then tries to accesses bad()'s stack which triggers Asan error. Simply compile the attached file with `-fsanitize=address -O2' and run it on ARM target. As I mentioned before, the stack shadow gets borked so by default you'll get an abort from Asan runtime: ================================================================= ==3366== ERROR: AddressSanitizer: stack-buffer-overflow on address 0xbefff797 at pc 0x8670 bp 0xbefff7ac sp 0xbefff7a4 READ of size 1 at 0xbefff797 thread T0 #0 0x866f (/dtv/usb/sda1/a.out+0x866f) #1 0x41632bcb (/mtd_exe/lib/libc-2.14.1.so+0x17bcb) ==3366== AddressSanitizer CHECK failed: /home/ygribov/gcc/gcc-master/libsanitizer/asan/asan_report.cc:250 "((name_end)) != (0)" (0x0, 0x0) #0 0x4003ace7 (/dtv/usb/sda1/libasan.so.0+0x12ce7) #1 0x400436fb (/dtv/usb/sda1/libasan.so.0+0x1b6fb) #2 0x4004121b (/dtv/usb/sda1/libasan.so.0+0x1921b) #3 0x4004136f (/dtv/usb/sda1/libasan.so.0+0x1936f) #4 0x40041feb (/dtv/usb/sda1/libasan.so.0+0x19feb) #5 0x4003b18b (/dtv/usb/sda1/libasan.so.0+0x1318b) #6 0x866f (/dtv/usb/sda1/a.out+0x866f) #7 0x41632bcb (/mtd_exe/lib/libc-2.14.1.so+0x17bcb) This is already a sign of invalid instrumentation. To get a more informative output, replace CHECK(name_end); with if(!name_end) return true; in libsanitizer/asan/asan_report.cc: ================================================================= ==3468== ERROR: AddressSanitizer: stack-buffer-overflow on address 0xbefff797 at pc 0x8670 bp 0xbefff7ac sp 0xbefff7a4 READ of size 1 at 0xbefff797 thread T0 #0 0x866f (/dtv/usb/sda1/a.out+0x866f) #1 0x41632bcb (/mtd_exe/lib/libc-2.14.1.so+0x17bcb) Shadow bytes around the buggy address: 0x37dffea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37dffeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37dffec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37dffed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37dffee0: 00 00 00 00 00 00 00 00 00 00 00 00 f4 f4 f4 f3 =>0x37dffef0: f3 f3[f3]00 00 00 f1 f1 f1 f1 01 f4 f4 f4 f3 00 0x37dfff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37dfff10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37dfff20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37dfff30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37dfff40: 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 righ 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 ASan internal: fe ==3468== ABORTING You can see that bad() function has not cleared the poisoned bytes. -Y
