* [Bug fortran/53379] [4.7 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
@ 2012-05-16 20:30 ` anlauf at gmx dot de
2012-05-18 7:36 ` [Bug fortran/53379] [4.7/4.8 " jb at gcc dot gnu.org
` (26 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anlauf at gmx dot de @ 2012-05-16 20:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #1 from Harald Anlauf <anlauf at gmx dot de> 2012-05-16 20:30:13 UTC ---
Solution: the function gfortran_runtime_error_at() should
call the abort. One might adjust this dependent on options.backtrace
if the core dump is not desired.
Patch: (should be applicable to 4.7 and 4.8 trunk)
Index: libgfortran/runtime/error.c
===================================================================
--- libgfortran/runtime/error.c (revision 184777)
+++ libgfortran/runtime/error.c (working copy)
@@ -333,7 +333,7 @@
st_vprintf (message, ap);
va_end (ap);
estr_write ("\n");
- exit (2);
+ sys_abort();
}
iexport(runtime_error_at);
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
2012-05-16 20:30 ` [Bug fortran/53379] " anlauf at gmx dot de
@ 2012-05-18 7:36 ` jb at gcc dot gnu.org
2012-05-18 7:43 ` burnus at gcc dot gnu.org
` (25 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jb at gcc dot gnu.org @ 2012-05-18 7:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-05-18 06:43:08 UTC ---
AFAICS, this is an intentional change in behavior. When I proposed making
backtracing enabled by default, there was some objections to the initial patch
on the grounds that the backtracing was too aggressive. See
http://gcc.gnu.org/ml/fortran/2011-05/msg00111.html
FWIW, if it is decided to change this, one could also consider changing
runtime_error() and internal_error() in the same way, though one would need to
audit the usage in libgfortran so that we don't generate a backtrace for a
"file not found" or similar "benign" error. Or in other words, "error
termination", as specified in the Fortran standard, should not lead to a
backtrace. See also the comment in runtime/error.c that talks about this.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
2012-05-16 20:30 ` [Bug fortran/53379] " anlauf at gmx dot de
2012-05-18 7:36 ` [Bug fortran/53379] [4.7/4.8 " jb at gcc dot gnu.org
@ 2012-05-18 7:43 ` burnus at gcc dot gnu.org
2012-05-18 14:46 ` jb at gcc dot gnu.org
` (24 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-18 7:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-18 07:35:17 UTC ---
(In reply to comment #2)
> AFAICS, this is an intentional change in behavior. When I proposed making
> backtracing enabled by default, there was some objections to the initial patch
> on the grounds that the backtracing was too aggressive.
I wonder whether one should add a more aggressive version of backtrace (which
could be internally pass backtrace == 2), which covers this case. Ditto for
some environment flag.
I have to admit that the description of
http://gcc.gnu.org/onlinedocs/gfortran/GFORTRAN_005fERROR_005fBACKTRACE.html is
misleading. And the meaning and relation of it to
http://gcc.gnu.org/onlinedocs/gfortran/GFORTRAN_005fSHOW_005fLOCUS.html is also
unclear.
> FWIW, if it is decided to change this, one could also consider changing
> runtime_error() and internal_error() in the same way, though one would need to
> audit the usage in libgfortran so that we don't generate a backtrace for a
> "file not found" or similar "benign" error.
I agree that, at least by default, "file not found" shouldn't print a backtrace
- though one could still think of it with some aggressive backtrace
flag/environment variable.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (2 preceding siblings ...)
2012-05-18 7:43 ` burnus at gcc dot gnu.org
@ 2012-05-18 14:46 ` jb at gcc dot gnu.org
2012-05-18 15:04 ` anlauf at gmx dot de
` (23 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jb at gcc dot gnu.org @ 2012-05-18 14:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #4 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-05-18 14:32:54 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > AFAICS, this is an intentional change in behavior. When I proposed making
> > backtracing enabled by default, there was some objections to the initial patch
> > on the grounds that the backtracing was too aggressive.
>
> I wonder whether one should add a more aggressive version of backtrace (which
> could be internally pass backtrace == 2), which covers this case. Ditto for
> some environment flag.
Well yes, but IMHO the best option would be to do the right thing by default,
making an option unnecessary. If anything, a bewildering array of options is an
usability issue.
For instance...
> I have to admit that the description of
> http://gcc.gnu.org/onlinedocs/gfortran/GFORTRAN_005fERROR_005fBACKTRACE.html is
> misleading. And the meaning and relation of it to
> http://gcc.gnu.org/onlinedocs/gfortran/GFORTRAN_005fSHOW_005fLOCUS.html is also
> unclear.
one wonders what is the purpose of GFORTRAN_SHOW_LOCUS. What value do we
provide by providing a means to NOT print out the filename/line information? I
think the answer is "none" and thus we should get rid of it, simplifying the
code and manual a tidy bit.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (3 preceding siblings ...)
2012-05-18 14:46 ` jb at gcc dot gnu.org
@ 2012-05-18 15:04 ` anlauf at gmx dot de
2012-05-29 14:40 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anlauf at gmx dot de @ 2012-05-18 15:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #5 from Harald Anlauf <anlauf at gmx dot de> 2012-05-18 15:02:07 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > FWIW, if it is decided to change this, one could also consider changing
> > runtime_error() and internal_error() in the same way, though one would need to
> > audit the usage in libgfortran so that we don't generate a backtrace for a
> > "file not found" or similar "benign" error.
>
> I agree that, at least by default, "file not found" shouldn't print a backtrace
> - though one could still think of it with some aggressive backtrace
> flag/environment variable.
One option is too add a runtime_fatal() that gets called by those checks
that are considered non-recoverable and deserve a backtrace if backtrace
is requested. Examples are array-bounds violations, invalid pointers,
etc. However, this requires an audit of the frontend.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (4 preceding siblings ...)
2012-05-18 15:04 ` anlauf at gmx dot de
@ 2012-05-29 14:40 ` rguenth at gcc dot gnu.org
2012-05-31 19:41 ` anlauf at gmx dot de
` (21 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-05-29 14:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
Target Milestone|--- |4.7.1
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (5 preceding siblings ...)
2012-05-29 14:40 ` rguenth at gcc dot gnu.org
@ 2012-05-31 19:41 ` anlauf at gmx dot de
2012-05-31 19:46 ` anlauf at gmx dot de
` (20 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anlauf at gmx dot de @ 2012-05-31 19:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #6 from Harald Anlauf <anlauf at gmx dot de> 2012-05-31 19:39:57 UTC ---
(In reply to comment #2)
> FWIW, if it is decided to change this, one could also consider changing
> runtime_error() and internal_error() in the same way, though one would need to
> audit the usage in libgfortran so that we don't generate a backtrace for a
> "file not found" or similar "benign" error. Or in other words, "error
> termination", as specified in the Fortran standard, should not lead to a
> backtrace. See also the comment in runtime/error.c that talks about this.
The patch in comment #1 changes only runtime_error_at, which appears to
be generated by the front-end only.
BTW: The program
program test
open(unit=10, file="/no/such/file", action='read')
end program test
gives with 4.7 and the patch in comment #1:
At line 2 of file test.f90 (unit = 10, file = '')
Fortran runtime error: File '/no/such/file' does not exist
while 4.6.2 with -fbacktrace produces:
At line 2 of file test.f90 (unit = 10, file = '')
Fortran runtime error: File '/no/such/file' does not exist
Backtrace for this error:
+ function test (0x80485F9)
at line 3 of file test.f90
+ /lib/libc.so.6(__libc_start_main+0xf3) [0xb73be003]
The latter error is generated by a call to runtime_error_at in
the compiled program, while the former error in open must be
generated somewhere in st_open and descendants.
Not relevant here, but note the missing file name in the first
line of the error message.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (6 preceding siblings ...)
2012-05-31 19:41 ` anlauf at gmx dot de
@ 2012-05-31 19:46 ` anlauf at gmx dot de
2012-05-31 19:47 ` anlauf at gmx dot de
` (19 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anlauf at gmx dot de @ 2012-05-31 19:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #7 from Harald Anlauf <anlauf at gmx dot de> 2012-05-31 19:41:03 UTC ---
(In reply to comment #2)
> FWIW, if it is decided to change this, one could also consider changing
> runtime_error() and internal_error() in the same way, though one would need to
> audit the usage in libgfortran so that we don't generate a backtrace for a
> "file not found" or similar "benign" error. Or in other words, "error
> termination", as specified in the Fortran standard, should not lead to a
> backtrace. See also the comment in runtime/error.c that talks about this.
The patch in comment #1 changes only runtime_error_at, which appears to
be generated by the front-end only.
BTW: The program
program test
open(unit=10, file="/no/such/file", action='read')
end program test
gives with 4.7 and the patch in comment #1:
At line 2 of file test.f90 (unit = 10, file = '')
Fortran runtime error: File '/no/such/file' does not exist
while 4.6.2 with -fbacktrace produces:
At line 2 of file test.f90 (unit = 10, file = '')
Fortran runtime error: File '/no/such/file' does not exist
Backtrace for this error:
+ function test (0x80485F9)
at line 3 of file test.f90
+ /lib/libc.so.6(__libc_start_main+0xf3) [0xb73be003]
The latter error is generated by a call to runtime_error_at in
the compiled program, while the former error in open must be
generated somewhere in st_open and descendants.
Not relevant here, but note the missing file name in the first
line of the error message.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (7 preceding siblings ...)
2012-05-31 19:46 ` anlauf at gmx dot de
@ 2012-05-31 19:47 ` anlauf at gmx dot de
2012-06-14 8:49 ` rguenth at gcc dot gnu.org
` (18 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anlauf at gmx dot de @ 2012-05-31 19:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #8 from Harald Anlauf <anlauf at gmx dot de> 2012-05-31 19:46:02 UTC ---
(In reply to comment #7)
> The latter error is generated by a call to runtime_error_at in
> the compiled program, while the former error in open must be
> generated somewhere in st_open and descendants.
Forget the first half of that statement, confusion on my side.
The error in open must always be generated somewhere in st_open
and descendants.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (8 preceding siblings ...)
2012-05-31 19:47 ` anlauf at gmx dot de
@ 2012-06-14 8:49 ` rguenth at gcc dot gnu.org
2012-09-20 10:27 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-06-14 8:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.1 |4.7.2
--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-14 08:48:45 UTC ---
GCC 4.7.1 is being released, adjusting target milestone.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (9 preceding siblings ...)
2012-06-14 8:49 ` rguenth at gcc dot gnu.org
@ 2012-09-20 10:27 ` jakub at gcc dot gnu.org
2013-02-20 21:21 ` jb at gcc dot gnu.org
` (16 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-09-20 10:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.2 |4.7.3
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-20 10:21:19 UTC ---
GCC 4.7.2 has been released.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (10 preceding siblings ...)
2012-09-20 10:27 ` jakub at gcc dot gnu.org
@ 2013-02-20 21:21 ` jb at gcc dot gnu.org
2013-04-11 8:00 ` [Bug fortran/53379] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org
` (15 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jb at gcc dot gnu.org @ 2013-02-20 21:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #11 from Janne Blomqvist <jb at gcc dot gnu.org> 2013-02-20 21:20:44 UTC ---
Looking at the frontend, calls to runtime_error_at are generated from
gfc_trans_runtime_check() and gfc_trans_runtime_error(). I went through calls
to these functions, and IMHO they all look like serious errors worthy of a
backtrace, with the exception of ALLOCATE/DEALLOCATE failures when STAT= is not
specified. In that case F2008 specifies that the processor must proceed with
error termination, and printing a backtrace for this case would be a bit
inconsistent with other cases of error termination.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8/4.9 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (11 preceding siblings ...)
2013-02-20 21:21 ` jb at gcc dot gnu.org
@ 2013-04-11 8:00 ` rguenth at gcc dot gnu.org
2013-12-29 11:55 ` dominiq at lps dot ens.fr
` (14 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-04-11 8:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.3 |4.7.4
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-11 07:59:42 UTC ---
GCC 4.7.3 is being released, adjusting target milestone.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8/4.9 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (12 preceding siblings ...)
2013-04-11 8:00 ` [Bug fortran/53379] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org
@ 2013-12-29 11:55 ` dominiq at lps dot ens.fr
2014-06-12 13:45 ` [Bug fortran/53379] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
` (13 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-12-29 11:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-12-29
Ever confirmed|0 |1
--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
If it is a regression (and it is), it should be marked as NEW. Any plans about
this PR?
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.7/4.8/4.9/4.10 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (13 preceding siblings ...)
2013-12-29 11:55 ` dominiq at lps dot ens.fr
@ 2014-06-12 13:45 ` rguenth at gcc dot gnu.org
2014-12-02 11:59 ` [Bug fortran/53379] [4.8/4.9/5 " Joost.VandeVondele at mat dot ethz.ch
` (12 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-06-12 13:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.4 |4.8.4
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (14 preceding siblings ...)
2014-06-12 13:45 ` [Bug fortran/53379] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
@ 2014-12-02 11:59 ` Joost.VandeVondele at mat dot ethz.ch
2014-12-04 21:05 ` anlauf at gmx dot de
` (11 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2014-12-02 11:59 UTC (permalink / raw)
To: gcc-bugs
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
0x60200000ef8c at pc 0x000000400c17 bp 0x7fff7f4bd220 sp 0x7fff7f4bd218
WRITE of size 4 at 0x60200000ef8c 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)
0x60200000ef8c is located 4 bytes to the left of 8-byte region
[0x60200000ef90,0x60200000ef98)
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
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (15 preceding siblings ...)
2014-12-02 11:59 ` [Bug fortran/53379] [4.8/4.9/5 " Joost.VandeVondele at mat dot ethz.ch
@ 2014-12-04 21:05 ` anlauf at gmx dot de
2014-12-05 8:46 ` Joost.VandeVondele at mat dot ethz.ch
` (10 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anlauf at gmx dot de @ 2014-12-04 21:05 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (16 preceding siblings ...)
2014-12-04 21:05 ` anlauf at gmx dot de
@ 2014-12-05 8:46 ` Joost.VandeVondele at mat dot ethz.ch
2014-12-19 13:28 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2014-12-05 8:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (17 preceding siblings ...)
2014-12-05 8:46 ` Joost.VandeVondele at mat dot ethz.ch
@ 2014-12-19 13:28 ` jakub at gcc dot gnu.org
2015-06-23 8:22 ` [Bug fortran/53379] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org
` (8 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-12-19 13:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.8/4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (18 preceding siblings ...)
2014-12-19 13:28 ` jakub at gcc dot gnu.org
@ 2015-06-23 8:22 ` rguenth at gcc dot gnu.org
2015-06-26 19:58 ` [Bug fortran/53379] [4.9/5/6 " jakub at gcc dot gnu.org
` (7 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-06-23 8:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.8.5 |4.9.3
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (19 preceding siblings ...)
2015-06-23 8:22 ` [Bug fortran/53379] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org
@ 2015-06-26 19:58 ` jakub at gcc dot gnu.org
2015-06-26 20:29 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-06-26 19:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (20 preceding siblings ...)
2015-06-26 19:58 ` [Bug fortran/53379] [4.9/5/6 " jakub at gcc dot gnu.org
@ 2015-06-26 20:29 ` jakub at gcc dot gnu.org
2015-08-31 16:55 ` Joost.VandeVondele at mat dot ethz.ch
` (5 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-06-26 20:29 UTC (permalink / raw)
To: gcc-bugs
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.9.3 |4.9.4
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (21 preceding siblings ...)
2015-06-26 20:29 ` jakub at gcc dot gnu.org
@ 2015-08-31 16:55 ` Joost.VandeVondele at mat dot ethz.ch
2015-08-31 21:12 ` fxcoudert at gcc dot gnu.org
` (4 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2015-08-31 16:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #21 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Janne Blomqvist from comment #11)
> Looking at the frontend, calls to runtime_error_at are generated from
> gfc_trans_runtime_check() and gfc_trans_runtime_error(). I went through
> calls to these functions, and IMHO they all look like serious errors worthy
> of a backtrace, with the exception of ALLOCATE/DEALLOCATE failures when
> STAT= is not specified. In that case F2008 specifies that the processor must
> proceed with error termination, and printing a backtrace for this case would
> be a bit inconsistent with other cases of error termination.
actually, I just created PR67414 where I ask for a backtrace on a failed
allocate if stat is not specified.
Since it is mostly a 'taste' issue when to emit a backtrace or not, I think it
makes sense to just make it an option flag, either never or always emit a
backtrace. The flag '-fbacktrace' already exists and it could imply generate a
backtrace on every 'error termination', run time error, or deadly signals.
I would find that very useful.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (22 preceding siblings ...)
2015-08-31 16:55 ` Joost.VandeVondele at mat dot ethz.ch
@ 2015-08-31 21:12 ` fxcoudert at gcc dot gnu.org
2015-09-04 22:04 ` jb at gcc dot gnu.org
` (3 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-08-31 21:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org
--- Comment #22 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Joost VandeVondele from comment #21)
> Since it is mostly a 'taste' issue when to emit a backtrace or not, I think
> it makes sense to just make it an option flag, either never or always emit a
> backtrace. The flag '-fbacktrace' already exists and it could imply generate
> a backtrace on every 'error termination', run time error, or deadly signals.
>
> I would find that very useful.
I strongly second that. Backtraces are useful for those informed, and can be
turned off (or ignored) by the non expert. So, I think every error termination
should print a backtrace.
That is: any case where we call abort(), or call exit() with non-zero status.
Except, possibly, user-specified non-zero status (like "STOP 42").
PS: Regarding the argument that many runtime errors already indicate the source
file and line number for the error, well… a backtrace has much more indication
since it indicates the entire code path for the error.
>From gcc-bugs-return-496019-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 31 21:49:48 2015
Return-Path: <gcc-bugs-return-496019-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32944 invoked by alias); 31 Aug 2015 21:49:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 32900 invoked by uid 48); 31 Aug 2015 21:49:41 -0000
From: "jb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/67414] [5 Regression] Error message on failed allocate
Date: Mon, 31 Aug 2015 21:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jb at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_file_loc
Message-ID: <bug-67414-4-V3WB6Gwd1c@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67414-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67414-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg02161.txt.bz2
Content-length: 570
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg414
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |https://gcc.gnu.org/ml/gcc-
| |patches/2015-08/msg01909.ht
| |ml
--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01909.html
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (23 preceding siblings ...)
2015-08-31 21:12 ` fxcoudert at gcc dot gnu.org
@ 2015-09-04 22:04 ` jb at gcc dot gnu.org
2015-09-04 22:17 ` jb at gcc dot gnu.org
` (2 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jb at gcc dot gnu.org @ 2015-09-04 22:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |https://gcc.gnu.org/ml/gcc-
| |patches/2015-09/msg00382.ht
| |ml
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
--- Comment #23 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Patch implementing "print backtrace on error termination" at
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00382.html
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (24 preceding siblings ...)
2015-09-04 22:04 ` jb at gcc dot gnu.org
@ 2015-09-04 22:17 ` jb at gcc dot gnu.org
2015-09-04 22:20 ` jb at gcc dot gnu.org
2015-09-05 6:55 ` Joost.VandeVondele at mat dot ethz.ch
27 siblings, 0 replies; 29+ messages in thread
From: jb at gcc dot gnu.org @ 2015-09-04 22:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #24 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Author: jb
Date: Fri Sep 4 22:17:11 2015
New Revision: 227503
URL: https://gcc.gnu.org/viewcvs?rev=227503&root=gcc&view=rev
Log:
PR 53379 Print backtrace on error termination.
2015-09-05 Janne Blomqvist <jb@gcc.gnu.org>
PR fortran/53379
* libgfortran.h (exit_error): New prototype.
* runtime/error.c (exit_error): New function.
(os_error): Call exit_error instead of exit.
(runtime_error): Likewise.
(runtime_error_at): Likewise.
(internal_error): Likewise.
(generate_error): Likewise.
(notify_std): Likewise.
* runtime/stop.c (error_stop_string): Likewise.
(error_stop_numeric): Likewise.
Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/error.c
trunk/libgfortran/runtime/stop.c
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (25 preceding siblings ...)
2015-09-04 22:17 ` jb at gcc dot gnu.org
@ 2015-09-04 22:20 ` jb at gcc dot gnu.org
2015-09-05 6:55 ` Joost.VandeVondele at mat dot ethz.ch
27 siblings, 0 replies; 29+ messages in thread
From: jb at gcc dot gnu.org @ 2015-09-04 22:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #25 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Fixed on trunk, closing.
(I don't think this should be backported, as older releases lack the new and
improved libbacktrace-based backtracing implementation.)
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
2012-05-16 17:17 [Bug fortran/53379] New: [4.7 Regression] No backtrace generated for array bounds violation anlauf at gmx dot de
` (26 preceding siblings ...)
2015-09-04 22:20 ` jb at gcc dot gnu.org
@ 2015-09-05 6:55 ` Joost.VandeVondele at mat dot ethz.ch
27 siblings, 0 replies; 29+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2015-09-05 6:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #26 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Janne Blomqvist from comment #25)
> Fixed on trunk, closing.
Thanks!
^ permalink raw reply [flat|nested] 29+ messages in thread