https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52673
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compiling the two tests with -fsanitize=address gives at run time
==74945==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff5d39d2b4 at pc 0x000102862c9d bp 0x7fff5d39d230 sp 0x7fff5d39d228
WRITE of size 4 at 0x7fff5d39d2b4 thread T0
#0 0x102862c9c in ss3_ (a.out+0x100000c9c)
#1 0x102862c46 in ss2_ (a.out+0x100000c46)
#2 0x102862bcc in ss1_ (a.out+0x100000bcc)
#3 0x102862cb3 in MAIN__ (a.out+0x100000cb3)
#4 0x102862cec in main (a.out+0x100000cec)
#5 0x7fff8e6de5c8 in start (libdyld.dylib+0x35c8)
#6 0x0 (<unknown module>)
Address 0x7fff5d39d2b4 is located in stack of thread T0 at offset 52 in frame
#0 0x102862b52 in ss1_ (a.out+0x100000b52)
This frame has 1 object(s):
[32, 44) 'ia' <== Memory access at offset 52 overflows this variable
...
for the first test and
==84952==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200000e044 at pc 0x00010384ea41 bp 0x7fff5c3b1210 sp 0x7fff5c3b1208
WRITE of size 4 at 0x60200000e044 thread T0
#0 0x10384ea40 in ss3_ (a.out+0x100000a40)
#1 0x10384e9ea in ss2_ (a.out+0x1000009ea)
#2 0x10384e94a in ss1_ (a.out+0x10000094a)
#3 0x10384ea57 in MAIN__ (a.out+0x100000a57)
#4 0x10384ea90 in main (a.out+0x100000a90)
#5 0x7fff8e6de5c8 in start (libdyld.dylib+0x35c8)
#6 0x0 (<unknown module>)
0x60200000e044 is located 8 bytes to the right of 12-byte region
[0x60200000e030,0x60200000e03c)
allocated by thread T0 here:
#0 0x1038a3697 in wrap_malloc (libasan.3.dylib+0x50697)
#1 0x10384e8f8 in ss1_ (a.out+0x1000008f8)
#2 0x10384ea57 in MAIN__ (a.out+0x100000a57)
#3 0x10384ea90 in main (a.out+0x100000a90)
#4 0x7fff8e6de5c8 in start (libdyld.dylib+0x35c8)
#5 0x0 (<unknown module>)
...
for the second one.
This PR has not evolved since three years and a half and now new options are
available to catch such issues. IMO This PR should be closed as WONTFIX.
