[Bug fortran/51197] New: [4.7 Regression] Backtrace information less useful

[Bug fortran/51197] New: [4.7 Regression] Backtrace information less useful

[anlauf at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

             Bug #: 51197
           Summary: [4.7 Regression] Backtrace information less useful
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: anlauf@gmx.de


Hi,

the backtrace facility is less useful with 4.7 than with 4.6.

Example:

program backtrace
  implicit none
  print *, foo (0.0)
contains
  function foo (x)
    real, intent (in) :: x
    real              :: foo
    foo = 1 / x
  end function foo
end program backtrace


gfortran 4.7 (svn revision 181390, arch is i686-pc-linux-gnu):

% /opt/gcc/4.7/bin/gfortran -g -fbacktrace gfcbug113.f90
-ffpe-trap=zero,overflow,invalid -static-libgfortran
% ./a.out

A fatal error occurred! Backtrace for this error:
#0  0x80588BF in _gfortrani_show_backtrace at backtrace.c:261
#1  0x80494B7 in _gfortrani_backtrace_handler at compile_options.c:46
#2  0xFFFFE3FF
#3  0x80493B3 in foo at gfcbug113.f90:8
#4  0x804940B in backtrace at gfcbug113.f90:3
Floating point exception (core dumped)


With gfortran 4.6:

Program received signal 8 (SIGFPE): Floating-point exception.

Backtrace for this error:
  + [0xffffe400]
  + function foo (0x80494B3)
    at line 8 of file gfcbug113.f90
  + function backtrace (0x804950C)
    at line 3 of file gfcbug113.f90
  + /lib/libc.so.6(__libc_start_main+0xe5) [0xb7641705]


Same for SIGSEGV etc.  It would be nice if I got back
the old behaviour where the actual error is displayed.
I'm not always good at guessing...

Harald

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-11-17 20:04:07 UTC ---
(In reply to comment #0)
> Hi,
> 
> the backtrace facility is less useful with 4.7 than with 4.6.
> 
> Example:
> 
> program backtrace
>   implicit none
>   print *, foo (0.0)
> contains
>   function foo (x)
>     real, intent (in) :: x
>     real              :: foo
>     foo = 1 / x
>   end function foo
> end program backtrace
> 
> 
> gfortran 4.7 (svn revision 181390, arch is i686-pc-linux-gnu):
> 
> % /opt/gcc/4.7/bin/gfortran -g -fbacktrace gfcbug113.f90
> -ffpe-trap=zero,overflow,invalid -static-libgfortran
> % ./a.out
> 
> A fatal error occurred! Backtrace for this error:
> #0  0x80588BF in _gfortrani_show_backtrace at backtrace.c:261
> #1  0x80494B7 in _gfortrani_backtrace_handler at compile_options.c:46
> #2  0xFFFFE3FF
> #3  0x80493B3 in foo at gfcbug113.f90:8
> #4  0x804940B in backtrace at gfcbug113.f90:3
> Floating point exception (core dumped)
> 
> 
> With gfortran 4.6:
> 
> Program received signal 8 (SIGFPE): Floating-point exception.
> 
> Backtrace for this error:
>   + [0xffffe400]
>   + function foo (0x80494B3)
>     at line 8 of file gfcbug113.f90
>   + function backtrace (0x804950C)
>     at line 3 of file gfcbug113.f90
>   + /lib/libc.so.6(__libc_start_main+0xe5) [0xb7641705]
> 
> 
> Same for SIGSEGV etc.  It would be nice if I got back
> the old behaviour where the actual error is displayed.
> I'm not always good at guessing...
> 

What exactly do you want?

In 4.7, the last line of the backtrace is

   "Floating point exception (core dumped)".

That matches the first line from 4.6

   "Program received signal 8 (SIGFPE): Floating-point exception."


In 4.7, the line 

#3  0x80493B3 in foo at gfcbug113.f90:8


contains all of the information from 4.6

  + function foo (0x80494B3)
    at line 8 of file gfcbug113.f90


-- 
steve

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[anlauf at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

--- Comment #2 from Harald Anlauf <anlauf at gmx dot de> 2011-11-17 20:17:32 UTC ---
(In reply to comment #1)

> > A fatal error occurred! Backtrace for this error:
> > #0  0x80588BF in _gfortrani_show_backtrace at backtrace.c:261
> > #1  0x80494B7 in _gfortrani_backtrace_handler at compile_options.c:46
> > #2  0xFFFFE3FF
> > #3  0x80493B3 in foo at gfcbug113.f90:8
> > #4  0x804940B in backtrace at gfcbug113.f90:3
> > Floating point exception (core dumped)
> > 
> > 
> > With gfortran 4.6:
> > 
> > Program received signal 8 (SIGFPE): Floating-point exception.
> > 
> > Backtrace for this error:
> >   + [0xffffe400]
> >   + function foo (0x80494B3)
> >     at line 8 of file gfcbug113.f90
> >   + function backtrace (0x804950C)
> >     at line 3 of file gfcbug113.f90
> >   + /lib/libc.so.6(__libc_start_main+0xe5) [0xb7641705]
> 
> What exactly do you want?
> 
> In 4.7, the last line of the backtrace is
> 
>    "Floating point exception (core dumped)".
> 
> That matches the first line from 4.6
> 
>    "Program received signal 8 (SIGFPE): Floating-point exception."
> 
> 
> In 4.7, the line 
> 
> #3  0x80493B3 in foo at gfcbug113.f90:8
> 
> 
> contains all of the information from 4.6
> 
>   + function foo (0x80494B3)
>     at line 8 of file gfcbug113.f90


Well, thanks for pointing out I was not precise enough.
While "reducing" the problem, I forgot that the difference
lies in where the line

> > Floating point exception (core dumped)

ends up.  Try redirecting stderr, you'll see that in the first
case (bash on linux) this line does *not* go to stderr,
while in the second case (4.6) it does.  When running programs
in a shell with output redirected, the information will end up
in different places.

So it would be nice to actually write the SIG* information also
to stderr.

Harald

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-11-18 06:41:15 UTC ---
(In reply to comment #2)
> Well, thanks for pointing out I was not precise enough.
> While "reducing" the problem, I forgot that the difference
> lies in where the line
> 
> > > Floating point exception (core dumped)
> 
> ends up.  Try redirecting stderr, you'll see that in the first
> case (bash on linux) this line does *not* go to stderr,
> while in the second case (4.6) it does.  When running programs
> in a shell with output redirected, the information will end up
> in different places.
> 
> So it would be nice to actually write the SIG* information also
> to stderr.

In 4.7 that's out of libgfortran's control, and I'd argue that fixing it would
make other issues worse. So in 4.7 the signal handler basically does

1) Print the backtrace.
2) Reset the handler for the signal to the default.
3) Raise the same signal.

This has the benefit that except for the printing of the backtrace, the
handling of the signal is identical to how it works with -fno-backtrace. E.g.
we get the correct process return value, and the decision whether to generate a
core dump or not is done by the OS in an identical fashion. If you check 4.6,
you get different process return codes for 1) default (-fno-backtrace), 2)
-fbacktrace 3) -fbacktrace -fdump-core. In the latter two cases the exit codes
have nothing to do with the fatal signal which was delivered. 

So to get back to the stdout/stderr issue, in 4.7 the last line of the output
is not printed by libgfortran but rather by the OS (libc?) default signal
handler for that signal (just like happens with -fno-backtrace). So libgfortran
has no say in where it goes. Of course, in 4.7 libgfortran could print a
similar line as in 4.6, but that would lead to duplicated output in the common
case where stdout and stderr go to the same place.

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011-11-18
     Ever Confirmed|0                           |1

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-18 13:44:38 UTC ---
(In reply to comment #2)
> So it would be nice to actually write the SIG* information also
> to stderr.

(In reply to comment #3)
> So to get back to the stdout/stderr issue, in 4.7 the last line of the output
> is not printed by libgfortran but rather by the OS (libc?) default signal
> handler for that signal (just like happens with -fno-backtrace). So libgfortran
> has no say in where it goes.

Harald, does this solve the issue? Or do you think that gfortran should replace
the standard handler?

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[anlauf at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

--- Comment #5 from Harald Anlauf <anlauf at gmx dot de> 2011-11-18 19:34:38 UTC ---
(In reply to comment #4)
> (In reply to comment #2)
> > So it would be nice to actually write the SIG* information also
> > to stderr.
> 
> (In reply to comment #3)
> > So to get back to the stdout/stderr issue, in 4.7 the last line of the output
> > is not printed by libgfortran but rather by the OS (libc?) default signal
> > handler for that signal (just like happens with -fno-backtrace). So libgfortran
> > has no say in where it goes.
> 
> Harald, does this solve the issue? Or do you think that gfortran should replace
> the standard handler?

If this means writing

Program received signal 8 (SIGFPE).

to stderr (which is where the backtrace dump goes)
before the actual backtrace, this would be perfect.

(I could even live well without "A fatal error occurred!",
but I'll leave that up to you.)

No need to mess with anything else.

Thanks,
Harald

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[anlauf at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

--- Comment #6 from Harald Anlauf <anlauf at gmx dot de> 2011-11-23 20:13:05 UTC ---
Created attachment 25905
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25905
Patch the reproduce desired behavior

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[anlauf at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

--- Comment #7 from Harald Anlauf <anlauf at gmx dot de> 2011-11-23 20:14:24 UTC ---
(In reply to comment #5)
> If this means writing
> 
> Program received signal 8 (SIGFPE).
> 
> to stderr (which is where the backtrace dump goes)
> before the actual backtrace, this would be perfect.
> 
> (I could even live well without "A fatal error occurred!",
> but I'll leave that up to you.)

I've just done this myself, using the function handler()
from a previous version of libgfortran/runtime/compile_options.c
and putting back the essential part.
With the attached patch, I get:


Program received signal 8 (SIGFPE): Floating-point exception.

Backtrace for this error:
#0  0x805891F in _gfortrani_show_backtrace at backtrace.c:261
#1  0x804951F in _gfortrani_backtrace_handler at compile_options.c:93
#2  0xFFFFE3FF
#3  0x80493B3 in foo at gfcbug113.f90:8
#4  0x804940B in backtrace at gfcbug113.f90:3

written to stderr when -fbacktrace is active, otherwise nothing.

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.0

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-09 19:54:11 UTC ---
FIXED on the trunk (4.7).

Harald, thanks for the patch!

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-09 19:53:32 UTC ---
Author: burnus
Date: Mon Jan  9 19:53:27 2012
New Revision: 183030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183030
Log:
2012-01-09  Harald Anlauf  <anlauf@gmx.de>
            Tobias Burnus  <burnus@net-b.de>

        PR fortran/51197
        * runtime/backtrace.c (show_backtrace): Modify wording written
        before the backtrace.
        * runtime/compile_options.c (show_signal): New function.
        (backtrace_handler): Use it.


Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/runtime/backtrace.c
    trunk/libgfortran/runtime/compile_options.c

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-10 09:32:34 UTC ---
Author: burnus
Date: Tue Jan 10 09:32:29 2012
New Revision: 183057

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183057
Log:
2012-01-10  Tobias Burnus  <burnus@net-b.de>

        PR fortran/51197
        * runtime/compile_options.c (show_signal): List
        more signals.


Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/runtime/compile_options.c