[Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|4.8.4   |4.8.5

--- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org ---
GCC 4.8.4 has been released.

[Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379

--- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 
---
(In reply to Harald Anlauf from comment #16)
 (In reply to Joost VandeVondele from comment #15)
  While if we use -fsanitize=address (at greatly increased cost), we actually
  get a Christmas tree with losts of colourful lights:
 
 I cannot use ASAN on any of the servers at work, as the
 administrators enforce strict limits on virtual memory.
 (See also PR 55517 on ASAN).

Sure, and one of the strong points of Fortran is that bounds checking works so
well, at a very low runtime cost... so replacing it with asan is not a general
purpose solution.

I believe your proposed patch in comment #1 is at least a reasonable partial
fix.

[Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379

--- Comment #16 from Harald Anlauf anlauf at gmx dot de ---
(In reply to Joost VandeVondele from comment #15)
 While if we use -fsanitize=address (at greatly increased cost), we actually
 get a Christmas tree with losts of colourful lights:

I cannot use ASAN on any of the servers at work, as the
administrators enforce strict limits on virtual memory.
(See also PR 55517 on ASAN).

[Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379

Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:

   What|Removed |Added

   Last reconfirmed|2013-12-29 00:00:00 |2014-12-2
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #15 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 
---
still fails with trunk, while this really was a useful feature.

 cat test.f90
MODULE m1
CONTAINS
SUBROUTINE foo(b)
 INTEGER, POINTER :: b(:)
 b(-1)=0
END SUBROUTINE foo
END MODULE

USE m1
INTEGER, POINTER :: a(:)
ALLOCATE(a(0:1))
CALL foo(a)
END

 gfortran -g -fbacktrace -fbounds-check test.f90  ./a.out
At line 5 of file test.f90
Fortran runtime error: Index '-1' of dimension 1 of array 'b' below lower bound
of 0

While if we use -fsanitize=address (at greatly increased cost), we actually get
a Christmas tree with losts of colourful lights:
 gfortran -g -fsanitize=address test.f90  ./a.out
=
==32762==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x6020ef8c at pc 0x00400c17 bp 0x7fff7f4bd220 sp 0x7fff7f4bd218
WRITE of size 4 at 0x6020ef8c thread T0
#0 0x400c16 in __m1_MOD_foo /data/vjoost/gnu/bugs/test.f90:5
#1 0x400d1a in MAIN__ /data/vjoost/gnu/bugs/test.f90:12
#2 0x400da2 in main /data/vjoost/gnu/bugs/test.f90:9
#3 0x3094e1ed5c in __libc_start_main (/lib64/libc.so.6+0x3094e1ed5c)
#4 0x400a48  (/data/vjoost/gnu/bugs/a.out+0x400a48)

0x6020ef8c is located 4 bytes to the left of 8-byte region
[0x6020ef90,0x6020ef98)
allocated by thread T0 here:
#0 0x7fb401b2ab1a in __interceptor_malloc
../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:38
#1 0x400cc2 in MAIN__ /data/vjoost/gnu/bugs/test.f90:11
#2 0x400da2 in main /data/vjoost/gnu/bugs/test.f90:9
#3 0x3094e1ed5c in __libc_start_main (/lib64/libc.so.6+0x3094e1ed5c)

SUMMARY: AddressSanitizer: heap-buffer-overflow
/data/vjoost/gnu/bugs/test.f90:5 __m1_MOD_foo
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=0x0c047fff9df0: fa[fa]00 fa fa fa 07 fa fa fa 07 fa fa fa 06 fa
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==32762==ABORTING