[Bug libfortran/67365] New: Spurious address printed in backtrace

[Bug libfortran/67365] New: Spurious address printed in backtrace

[jb at gcc dot gnu.org]

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

            Bug ID: 67365
           Summary: Spurious address printed in backtrace
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

Following the recent update to use libbacktrace instead of fork+exec of
addr2line in libgfortran, a small test program I had lying around shows a
strange address as the first stack frame. The program:

program bt
  implicit none
  call a
contains
  subroutine c(a, b, res)
    real(8) :: a, b, res
    res = a / b
  end subroutine c

  subroutine b
    real(8) :: res
    call c(0.d0, 0.d0, res)
    print *, res
  end subroutine b

  subroutine a
    call b
  end subroutine a

end program bt

Compile with
$ gfortran -g -ffpe-trap=zero,invalid -o bt2static -static bt2.f90
$ ./bt2static

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x43056f in ???
#1  0x40118d in c
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:7
#2  0x401103 in b
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:12
#3  0x4010c4 in a
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:17
#4  0x4010d3 in bt
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:3
#5  0x4011d9 in main
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:3
[1]    29115 floating point exception (core dumped)  ./bt2static


So the first stack frame has some address where the corresponding symbol isn't
found. gdb doesn't find it either:

❯ gdb ./bt2static
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bt2static...done.
(gdb) r
Starting program:
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2static 

Program received signal SIGFPE, Arithmetic exception.
0x000000000040118d in c (a=0, b=0, res=2.1738888417014848e-322) at bt2.f90:7
7           res = a / b
(gdb) c
Continuing.

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x43056f in ???
#1  0x40118d in c
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:7
#2  0x401103 in b
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:12
#3  0x4010c4 in a
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:17
#4  0x4010d3 in bt
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:3
#5  0x4011d9 in main
        at
/home/janne/src/gfortran/my-patches/pr48931-backtrace-abort/bt2.f90:3

Program received signal SIGFPE, Arithmetic exception.
0x000000000040118d in c (a=0, b=0, res=2.1738888417014848e-322) at bt2.f90:7
7           res = a / b
(gdb) bt
#0  0x000000000040118d in c (a=0, b=0, res=2.1738888417014848e-322) at
bt2.f90:7
#1  0x0000000000401104 in b () at bt2.f90:12
#2  0x00000000004010c5 in a () at bt2.f90:17
#3  0x00000000004010d4 in bt () at bt2.f90:3
#4  0x00000000004011da in main (argc=1, argv=0x7fffffffdcce) at bt2.f90:3
#5  0x000000000042a3bc in __libc_start_main ()
#6  0x0000000000400fb7 in _start ()
(gdb) info symbol 0x43056f
No symbol matches 0x43056f.


Any clue where this address comes from?
>From gcc-bugs-return-495694-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 26 20:23:35 2015
Return-Path: <gcc-bugs-return-495694-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 47620 invoked by alias); 26 Aug 2015 20:23:35 -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 47596 invoked by uid 55); 26 Aug 2015 20:23:30 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66902] _S_debug_messages is unneccessary public
Date: Wed, 26 Aug 2015 20:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: redi 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:
Message-ID: <bug-66902-4-nd2c8GcJ85@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66902-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66902-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/msg01836.txt.bz2
Content-length: 486

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf902

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Wed Aug 26 20:22:58 2015
New Revision: 227228

URL: https://gcc.gnu.org/viewcvs?rev"7228&root=gcc&view=rev
Log:
libstdc++/66902 Make _S_debug_messages static.

        PR libstdc++/66902
        * src/c++11/debug.cc (_S_debug_messages): Give internal linkage.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/src/c++11/debug.cc

[Bug libfortran/67365] Spurious address printed in backtrace

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-28
     Ever confirmed|0                           |1

--- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Confirmed. This apparently has to do with FPE exceptions and signal handling,
but I don' know how. This was already present with the previous backtrace
implementation:

Backtrace for this error:
#0  0x7F75B429B467
#1  0x7F75B429BAAE
#2  0x7F75B37A264F
#3  0x4008DB in c at a.f90:7
#4  0x400856 in b at a.f90:12
#5  0x400828 in a at a.f90:17
#6  0x400833 in bt at a.f90:3
Floating point exception (core dumped)

(for example with gfortran 4.8.3). I will look into it.

If one makes a static executable and looks at the backtrace, the address
printed is in the vicinity of the following symbols (from "nm" output):

__libc_action
__restore_rt

[Bug libfortran/67365] Spurious address printed in backtrace

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #2 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #1)
> Confirmed. This apparently has to do with FPE exceptions and signal
> handling, but I don' know how.

Confirmed, that address is related to signal handler. Even in a C program, I
see it in-between the handler (which, in libgfortran's case, we hide as a
private symbol) and the user-provided functions:

[fx@kelvin irun]$ cat a.c
#define _GNU_SOURCE
#include <fenv.h>
#include <stdio.h>
#include <signal.h>

extern void _gfortran_backtrace (void);

void handler (int sig)
{
  signal (SIGFPE, SIG_DFL);
  _gfortran_backtrace();
}

double bar (double x)
{
  return x / x;
}

int main (void)
{
  double x, y;

  feenableexcept (FE_INVALID | FE_DIVBYZERO);
  signal (SIGFPE, handler);
  x = 0;
  y = bar (x);
  printf ("%g\n", y);
}
[fx@kelvin irun]$ ./bin/gcc a.c -static -lgfortran -lquadmath -lm -g && ./a.out
#0  0x4010ce handler
        /home/fx/gcc/irun/a.c:11
#1  0x4306df ???
#2  0x4010e0 bar
        /home/fx/gcc/irun/a.c:16
#3  0x401122 main
        /home/fx/gcc/irun/a.c:26
Floating point exception (core dumped)


I'm not sure there is much we can do here. I am CC'ing Ian, who probably knows
best.

[Bug libfortran/67365] Spurious address printed in backtrace

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
The missing address is part of the signal handling code.  It's the code that
returns to normal execution after the signal handler completes, by calling the
rt_sigreturn system call.  The backtrace code routinely decrements the return
address by 1, so that it can report the file/line of the function call rather
than the line that follows the call.  In this case, decrementing by 1 gives it
an address 1 byte before _restore_rt.  It can't find any file/line information
for that one byte, so you get a ???.

This code is very processor-specific.  GCC's internal unwind library knows that
we are looking at a signal handler return, but it doesn't expose the
information in any way that I can see (the _Unwind_IsSignalFrame function
returns true for the function in which the signal occurred, which is the frame
above the frame we are talking about).

I think the best fix is going to be to add a new flag to _Unwind_Context:
SIGRETURN_BIT or something, to indicate that the current context is a signal
handler frame.  Then we can add an _Unwind_IsSigreturn function so that the
unwind code can check that bit.  Then libbacktrace can return something like
<signal handler> as gdb does.  (gdb currently uses processor-specific code for
this.)