public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/51197] [4.7 Regression] Backtrace information less useful
Date: Fri, 18 Nov 2011 07:34:00 -0000	[thread overview]
Message-ID: <bug-51197-4-9V2UrtEvCK@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-51197-4@http.gcc.gnu.org/bugzilla/>

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.


  parent reply	other threads:[~2011-11-18  6:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17 20:17 [Bug fortran/51197] New: " anlauf at gmx dot de
2011-11-17 20:25 ` [Bug fortran/51197] " kargl at gcc dot gnu.org
2011-11-17 20:55 ` anlauf at gmx dot de
2011-11-18  7:34 ` jb at gcc dot gnu.org [this message]
2011-11-18 14:09 ` burnus at gcc dot gnu.org
2011-11-18 19:51 ` anlauf at gmx dot de
2011-11-23 20:31 ` anlauf at gmx dot de
2011-11-23 21:00 ` anlauf at gmx dot de
2011-12-05 14:23 ` rguenth at gcc dot gnu.org
2011-12-06 14:04 ` rguenth at gcc dot gnu.org
2012-01-09 19:54 ` burnus at gcc dot gnu.org
2012-01-09 19:55 ` burnus at gcc dot gnu.org
2012-01-10  9:33 ` burnus at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-51197-4-9V2UrtEvCK@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).