[Bug fortran/54572] New: Use libbacktrace library

[Bug fortran/54572] New: Use libbacktrace library

[burnus at gcc dot gnu.org]

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

             Bug #: 54572
           Summary: Use libbacktrace library
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: jb@gcc.gnu.org


Ian has created a shiny libbacktrace libray which should be used to replace the
current implementation in libgfortran/runtime/backtrace.c, which uses 
unwinder and, if available, addr2line.

libbacktrace is installed both as host library (i.e. for backtraces of the
compiler when an ICE occurs) and as target library, to be used by "go" and
possibly other users (e.g. libgfortran).


TODO:


a) Enable the building of the target library:

--- ./gcc/fortran/config-lang.in.orig   2011-05-10 23:12:01.000000000 +0200
+++ ./gcc/fortran/config-lang.in        2012-09-13 22:06:38.000000000 +0200
@@ -30 +30 @@ compilers="f951\$(exeext)"
-target_libs=target-libgfortran
+target_libs="target-libgfortran target-libbacktrace"


b) Add --disable-target-libbacktrace to the toplevel configure to disable
libbacktrace; e.g. for our embedded users. (toplevel implies a sync with
sourceware; watch out for "go" which also uses the target library, check that
"go" is still be working without target libbacktrace.)


c) Configure check: Check whether the library is available. (See
libgfortran/acinclude.m4's LIBGFOR_CHECK_FLOAT128 for some ideas how one can
test this.)

d) Configure check 2: Check whether BACKTRACE_SUPPORTED is set to 0 (->
backtrace-supported.h), in that case, it is also pointless to build the
support.



e) Replace the current version by calls to libbacktrace.

Almost latest version of the patch:
  http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00806.html
Or wait a while and browse libbacktrace/ directly.

  * backtrace-supported.h contains BACKTRACE_USES_MALLOC
    and BACKTRACE_SUPPORTED

  * Available functions are listed in backtrace.h


[The current version of libbacktrace only handles ELF+DWARF; one could consider
keeping the other version for a while. On the other hand, I assume that other
formats will soon be supported.]

[Bug fortran/54572] Use libbacktrace library

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

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

--- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2012-09-15 11:25:35 UTC ---
You need unwind frames present for this to work, i.e. the space (and to some
extent optimization-reducing - yes I'm sure) overhead of -funwind-tables. (Only
x86_64 has this on, effectively.)

[Bug fortran/54572] Use libbacktrace library

[jb at gcc dot gnu.org]

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

--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-09-16 08:33:42 UTC ---
(In reply to comment #1)
> You need unwind frames present for this to work, i.e. the space (and to some
> extent optimization-reducing - yes I'm sure) overhead of -funwind-tables. (Only
> x86_64 has this on, effectively.)

How is this different from the current backtracing implementation in
libgfortran?

(That being said, we should probably modify the driver program to always add
-funwind-tables, which IIRC isn't done today)

[Bug fortran/54572] Use libbacktrace library

[hp at gcc dot gnu.org]

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

--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2012-09-16 23:16:02 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > You need unwind frames present for this to work,

> How is this different from the current backtracing implementation in
> libgfortran?

Right, it already has that dependence, sorry for the noise.

[Bug fortran/54572] Use libbacktrace library

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-11-25
         AssignedTo|unassigned at gcc dot       |jb at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #4 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-11-25 15:10:07 UTC ---
I have a patch, just need to clean it up a bit and test.

[Bug fortran/54572] Use libbacktrace library

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

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

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-11-26 16:43:16 UTC ---
Bummer, I've hit a snag. Otherwise the patch works, but trying to do a symbolic
backtrace from a signal handler fails (which was sort of the entire idea of
using libbacktrace instead of forking addr2line). Ian, any idea what might go
wrong?

With the testcase below which is expected to fail due to a div-by-zero:

module test
contains
  subroutine c(num, denum, res)
    integer :: num, denum, res
    res = num / denum
  end subroutine c

  subroutine b(n, d, r)
    integer :: n, d, r
    call c(n, d, r)
  end subroutine b

  subroutine a(n, d, r)
    integer :: n, d, r
    call b(n, d, r)
  end subroutine a
end module test

program bt
  use test
  integer :: res
  call a(1, 0, res)
  print *, res
end program bt

compiled with "-g" the result is

$ ./bt2.g 

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

Backtrace for this error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
Segmentation fault (core dumped)

backtrace via gdb:

(gdb) r
Starting program:
/home/janne/src/gfortran/my-patches/pr54572-libbacktrace/bt2.g 

Program received signal SIGFPE, Arithmetic exception.
0x000000000040086b in __test_MOD_c ()
(gdb) c
Continuing.

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

Backtrace for this error:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bb2a1c in read_uint32 () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
(gdb) bt
#0  0x00007ffff7bb2a1c in read_uint32 () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
#1  0x00007ffff7bb53be in backtrace_dwarf_add () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
#2  0x00007ffff7bb72a7 in elf_add () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
#3  0x00007ffff7bb7696 in backtrace_initialize () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
#4  0x00007ffff7bb630d in fileline_initialize () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
#5  0x00007ffff7bb6427 in backtrace_pcinfo () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
#6  0x00007ffff7bb6831 in unwind () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
#7  0x00007ffff75b9ec9 in _Unwind_Backtrace () from
/home/janne/src/gfortran/trunk/install/lib64/libgcc_s.so.1
#8  0x00007ffff7bb6885 in backtrace_full () from
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3
#9  0x00007ffff7ad527e in _gfortrani_show_backtrace () at
../../../trunk-git/libgfortran/runtime/backtrace.c:92
#10 0x00007ffff7ad5888 in _gfortrani_backtrace_handler ()
    at ../../../trunk-git/libgfortran/runtime/compile_options.c:129
#11 <signal handler called>
#12 0x000000000040086b in __test_MOD_c ()
#13 0x0000000000400848 in __test_MOD_b ()
#14 0x000000000040081b in __test_MOD_a ()
#15 0x0000000000400898 in MAIN__ ()
#16 0x0000000000400930 in main ()
#17 0x00007ffff6fd176d in __libc_start_main (main=0x4008fc <main>, argc=1,
ubp_av=0x7fffffffd718, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd708)
at libc-start.c:226
#18 0x0000000000400709 in _start ()


For comparison, if I compile the testcase without "-g" then it works as
expected:

$ ./bt2

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

Backtrace for this error:
0x7fcf58e202a0
0x7fcf58e20887
0x7fcf5833149f
0x40086b
0x400847
0x40081a
0x400897
0x40092f
0x7fcf5831c76c
0x400708
Floating point exception (core dumped)

[Bug fortran/54572] Use libbacktrace library

[jb at gcc dot gnu.org]

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

--- Comment #6 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-11-26 16:46:08 UTC ---
Created attachment 28779
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28779
Patch to use libbacktrace

[Bug fortran/54572] Use libbacktrace library

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor <ian at airs dot com> 2012-11-26 23:02:46 UTC ---
Why are there no line numbers in the backtrace from gdb?  You said you compiled
with -g.  Are you sure that libbacktrace itself was compiled with -g?

[Bug fortran/54572] Use libbacktrace library

[ian at airs dot com]

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

--- Comment #8 from Ian Lance Taylor <ian at airs dot com> 2012-11-26 23:08:45 UTC ---
The crash within libbacktrace is occurring as it tries to read the debug info. 
This is presumably a bug in libbacktrace, but I don't know what the problem is
without more information.  libbacktrace is pretty careful to only read memory
that was explicitly read.  There is presumably a bug there, but I don't know
what it is.

I doubt the fact that a signal occurred has anything to do with this.  There
seems to be something odd about the debug info, as shown both by the fact that
libbacktrace crashes trying to read it and that gdb does not display file/line
information.

[Bug fortran/54572] Use libbacktrace library

[jb at gcc dot gnu.org]

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

--- Comment #9 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-11-27 08:58:59 UTC ---
(In reply to comment #7)
> Why are there no line numbers in the backtrace from gdb?  You said you compiled
> with -g.  Are you sure that libbacktrace itself was compiled with -g?

I meant that I compiled the Fortran testcase with -g; GCC itself, including
libbacktrace, was built with default flags which ought to be "-O2 -g", but I
didn't specifically check how libbacktrace was built. Now that you mention it,
it does indeed seem like libbacktrace doesn't have debug symbols for some
reason.

(In reply to comment #8)
> The crash within libbacktrace is occurring as it tries to read the debug info. 
> This is presumably a bug in libbacktrace, but I don't know what the problem is
> without more information.  libbacktrace is pretty careful to only read memory
> that was explicitly read.  There is presumably a bug there, but I don't know
> what it is.
> 
> I doubt the fact that a signal occurred has anything to do with this.  There
> seems to be something odd about the debug info, as shown both by the fact that
> libbacktrace crashes trying to read it and that gdb does not display file/line
> information.

I forgot to mention, that I'm able to get a symbolic backtrace from outside a
signal handler. Though in that case my testcase used external procedures rather
than module procedures, so I guess it's possible there's a bug in handling
debug info for module procedures. I'll recheck this..

[Bug fortran/54572] Use libbacktrace library

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-11-27 09:32:55 UTC ---
(In reply to comment #6)
> Created attachment 28779 [details]
> Patch to use libbacktrace

I have to apply the following patch on your patch in order to be able to
compile it.  ("MULTIBUILDTOP" is empty here and the library is not in
"/libbacktrace".)

--- libgfortran-backtrace-pr54572.diff.orig     2012-11-27 10:09:13 +0100
+++ libgfortran-backtrace-pr54572.diff  2012-11-27 10:12:05 +0100
@@ -51 +51 @@ index abc23cd..dd325bd 100644
-+            -I$(MULTIBUILDTOP)/../libbacktrace \
++            -I$(MULTIBUILDTOP)../libbacktrace \



Additionally, I wonder whether one should have:

--- a/Makefile.def
+++ b/Makefile.def
 languages = { language=fortran;        gcc-check-target=check-fortran;
                                lib-check-target=check-target-libquadmath;
+                               lib-check-target=check-target-libbacktrace;
                                lib-check-target=check-target-libgfortran; };
 languages = { language=java;   gcc-check-target=check-java;




And in the same file, I wonder which of the following two is correct:

+dependencies = { module=all-target-libgfortran; on=all-target-libbacktrace; };

or

+dependencies = { module=configure-target-libgfortran;
on=all-target-libbacktrace; };

[Bug fortran/54572] Use libbacktrace library

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-11-27 10:05:50 UTC ---
After compiling comment 5 with my changes of comment 10, I get:

Backtrace for this error:
0x2b9567c7ca0d _gfortrani_show_backtrace
        /projects/tob/gcc-git/gcc/libgfortran/runtime/backtrace.c:92
0x2b9567c7d017 _gfortrani_backtrace_handler
        /projects/tob/gcc-git/gcc/libgfortran/runtime/compile_options.c:129
0x2b95687503ef ???
        ???:0
0x40086b __test_MOD_c
        /dev/shm/foo.f90:5
0x400847 __test_MOD_b
        /dev/shm/foo.f90:10
0x40081a __test_MOD_a
        /dev/shm/foo.f90:15
0x400897 bt
        /dev/shm/foo.f90:22
0x40092f main
        /dev/shm/foo.f90:20


And before (i.e with addr2line), I got:

Backtrace for this error:
#0  0x2AC1DC8D7AE7
#1  0x2AC1DC8D80F2
#2  0x2AC1DD3A43EF
#3  0x40086B in __test_MOD_c at foo.f90:5
#4  0x400847 in __test_MOD_b at foo.f90:10
#5  0x40081A in __test_MOD_a at foo.f90:15
#6  0x400897 in bt at foo.f90:22

[Bug fortran/54572] Use libbacktrace library

[jb at gcc dot gnu.org]

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

--- Comment #12 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-11-30 21:56:29 UTC ---
(In reply to comment #9)
> (In reply to comment #7)
> > Why are there no line numbers in the backtrace from gdb?  You said you compiled
> > with -g.  Are you sure that libbacktrace itself was compiled with -g?
> 
> I meant that I compiled the Fortran testcase with -g; GCC itself, including
> libbacktrace, was built with default flags which ought to be "-O2 -g", but I
> didn't specifically check how libbacktrace was built. Now that you mention it,
> it does indeed seem like libbacktrace doesn't have debug symbols for some
> reason.

So yes, libbacktrace is compiled with debug information, however, the issue was
that gdb 7.4 couldn't handle some DWARF-4 specific stuff which for some reason
were generated for the libbacktrace object files (??). I upgraded to GDB 7.5,
and now I get the following backtrace:

(gdb) r
Starting program:
/home/janne/src/gfortran/my-patches/pr54572-libbacktrace/bt2.g 

Program received signal SIGFPE, Arithmetic exception.
0x000000000040086b in test::c (num=1, denum=0, res=32767) at bt2.f90:5
5           res = num / denum
(gdb) c
Continuing.

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

Backtrace for this error:

Program received signal SIGSEGV, Segmentation fault.
read_uint32 (buf=buf@entry=0x7fffffffc730) at
../../../trunk-git/libbacktrace/dwarf.c:458
458         return (((uint32_t) p[3] << 24) | ((uint32_t) p[2] << 16)
(gdb) bt
#0  read_uint32 (buf=buf@entry=0x7fffffffc730) at
../../../trunk-git/libbacktrace/dwarf.c:458
#1  0x00007ffff7bb53be in build_address_map (addrs=0x7fffffffc710,
data=0x7fffffffcf1c, 
    error_callback=0x7ffff7ad51f0 <error_callback>, is_bigendian=0,
dwarf_str_size=360, 
    dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_ranges_size=0, 
    dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>,
dwarf_abbrev_size=253, 
    dwarf_abbrev=0x7ffff7ff708f
"\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", 
    dwarf_info_size=484, dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out
of bounds>, 
    base_address=<optimized out>, state=<optimized out>) at
../../../trunk-git/libbacktrace/dwarf.c:1299
#2  build_dwarf_data (data=0x7fffffffcf1c, error_callback=0x7ffff7ad51f0
<error_callback>, is_bigendian=0, 
    dwarf_str_size=360, dwarf_str=0x7ffff7ff71e3 "integer(kind=4)",
dwarf_ranges_size=0, 
    dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>,
dwarf_abbrev_size=253, 
    dwarf_abbrev=0x7ffff7ff708f
"\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", 
    dwarf_line_size=<optimized out>, dwarf_line=<optimized out>,
dwarf_info_size=484, 
    dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out of bounds>,
base_address=<optimized out>, 
    state=<optimized out>) at ../../../trunk-git/libbacktrace/dwarf.c:2822
#3  backtrace_dwarf_add (state=state@entry=0x7ffff7ff8000,
base_address=base_address@entry=0, 
    dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out of bounds>,
dwarf_info_size=484, 
    dwarf_line=0x7ffff7ff718c "S", dwarf_line_size=87, 
    dwarf_abbrev=0x7ffff7ff708f
"\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", 
    dwarf_abbrev_size=253, dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000
out of bounds>, dwarf_ranges_size=0, 
    dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_str_size=360,
is_bigendian=0, 
    error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>,
data=data@entry=0x7fffffffcf1c, 
    fileline_fn=fileline_fn@entry=0x7fffffffcb18) at
../../../trunk-git/libbacktrace/dwarf.c:2881
#4  0x00007ffff7bb72a7 in elf_add (state=state@entry=0x7ffff7ff8000,
descriptor=<optimized out>, 
    base_address=base_address@entry=0,
error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>, 
    data=data@entry=0x7fffffffcf1c,
fileline_fn=fileline_fn@entry=0x7fffffffcb18, 
    found_sym=found_sym@entry=0x7fffffffcb10,
found_dwarf=found_dwarf@entry=0x7fffffffcb14)
    at ../../../trunk-git/libbacktrace/elf.c:757
#5  0x00007ffff7bb7696 in backtrace_initialize
(state=state@entry=0x7ffff7ff8000, descriptor=<optimized out>, 
    error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>,
data=data@entry=0x7fffffffcf1c, 
    fileline_fn=fileline_fn@entry=0x7fffffffcb98) at
../../../trunk-git/libbacktrace/elf.c:858
#6  0x00007ffff7bb630d in fileline_initialize
(state=state@entry=0x7ffff7ff8000, 
    error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>,
data=data@entry=0x7fffffffcf1c)
    at ../../../trunk-git/libbacktrace/fileline.c:144
#7  0x00007ffff7bb6427 in backtrace_pcinfo (state=0x7ffff7ff8000,
pc=140737348719229, 
    callback=0x7ffff7ad5170 <full_callback>, error_callback=0x7ffff7ad51f0
<error_callback>, data=0x7fffffffcf1c)
    at ../../../trunk-git/libbacktrace/fileline.c:184
#8  0x00007ffff7bb6831 in unwind (context=<optimized out>,
vdata=0x7fffffffced0)
    at ../../../trunk-git/libbacktrace/backtrace.c:83
#9  0x00007ffff75b9f49 in _Unwind_Backtrace (trace=trace@entry=0x7ffff7bb67e0
<unwind>, 
    trace_argument=trace_argument@entry=0x7fffffffced0) at
../../../trunk-git/libgcc/unwind.inc:295
#10 0x00007ffff7bb6885 in backtrace_full (state=state@entry=0x7ffff7ff8000,
skip=skip@entry=0, 
    callback=callback@entry=0x7ffff7ad5170 <full_callback>, 
    error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>,
data=data@entry=0x7fffffffcf1c)
    at ../../../trunk-git/libbacktrace/backtrace.c:106
#11 0x00007ffff7ad527e in _gfortrani_show_backtrace
(in_signal_handler=in_signal_handler@entry=1)
    at ../../../trunk-git/libgfortran/runtime/backtrace.c:92
#12 0x00007ffff7ad5888 in _gfortrani_backtrace_handler (signum=8)
    at ../../../trunk-git/libgfortran/runtime/compile_options.c:129
#13 <signal handler called>
#14 0x000000000040086b in test::c (num=1, denum=0, res=32767) at bt2.f90:5
#15 0x0000000000400848 in test::b (n=1, d=0, r=32767) at bt2.f90:10
---Type <return> to continue, or q <return> to quit---
#16 0x000000000040081b in test::a (n=1, d=0, r=32767) at bt2.f90:15
#17 0x0000000000400898 in bt () at bt2.f90:22
#18 0x0000000000400930 in main (argc=1, argv=0x7fffffffdac1) at bt2.f90:20
#19 0x00007ffff6fd176d in __libc_start_main (main=0x4008fc <main>, argc=1,
ubp_av=0x7fffffffd718, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd708)
at libc-start.c:226
#20 0x0000000000400709 in _start ()


As an aside, my binutils is also old enough (2.22) to not handle DWARF-4 fully
(e.g. addr2line doesn't understand it, objdump -W complains..), but as I
understand it libbacktrace has a self-contained dwarf parser so it shouldn't
matter, right?

> (In reply to comment #8)
> > The crash within libbacktrace is occurring as it tries to read the debug info. 
> > This is presumably a bug in libbacktrace, but I don't know what the problem is
> > without more information.  libbacktrace is pretty careful to only read memory
> > that was explicitly read.  There is presumably a bug there, but I don't know
> > what it is.
> > 
> > I doubt the fact that a signal occurred has anything to do with this.  There
> > seems to be something odd about the debug info, as shown both by the fact that
> > libbacktrace crashes trying to read it and that gdb does not display file/line
> > information.
> 
> I forgot to mention, that I'm able to get a symbolic backtrace from outside a
> signal handler. Though in that case my testcase used external procedures rather
> than module procedures, so I guess it's possible there's a bug in handling
> debug info for module procedures. I'll recheck this..

Another strange thing, if I compile the test example from #c5 with "-g
-static", then it works as expected. As a summary, 

1) -g => fails with backtrace above

2) -g -static => success, symbolic backtrace

3) Without -g => success, non-symbolic backtrace


I'm baffled..

[Bug fortran/54572] Use libbacktrace library

[jb at gcc dot gnu.org]

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

--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-11-30 22:03:43 UTC ---
(In reply to comment #10)
> (In reply to comment #6)
> > Created attachment 28779 [details]
> > Patch to use libbacktrace
> 
> I have to apply the following patch on your patch in order to be able to
> compile it.  ("MULTIBUILDTOP" is empty here and the library is not in
> "/libbacktrace".)
> 
> --- libgfortran-backtrace-pr54572.diff.orig     2012-11-27 10:09:13 +0100
> +++ libgfortran-backtrace-pr54572.diff  2012-11-27 10:12:05 +0100
> @@ -51 +51 @@ index abc23cd..dd325bd 100644
> -+            -I$(MULTIBUILDTOP)/../libbacktrace \
> ++            -I$(MULTIBUILDTOP)../libbacktrace \

Good point, fixed. Also the previous line had the same issue, fixed that as
well.

> 
> 
> 
> Additionally, I wonder whether one should have:
> 
> --- a/Makefile.def
> +++ b/Makefile.def
>  languages = { language=fortran;        gcc-check-target=check-fortran;
>                                 lib-check-target=check-target-libquadmath;
> +                               lib-check-target=check-target-libbacktrace;
>                                 lib-check-target=check-target-libgfortran; };
>  languages = { language=java;   gcc-check-target=check-java;
> 
> 
> 
> 
> And in the same file, I wonder which of the following two is correct:
> 
> +dependencies = { module=all-target-libgfortran; on=all-target-libbacktrace; };
> 
> or
> 
> +dependencies = { module=configure-target-libgfortran;
> on=all-target-libbacktrace; };

I modeled this after how the go frontend does it. The idea, AFAICS, is that
libbacktrace is always built as a hard dependency on libgfortran, however, if
libbacktrace doesn't support the target, BACKTRACE_SUPPORTED is set to 0 and a
dummy implementation is provided. That is, we can always unconditionally rely
on libbacktrace being present. This is different from e.g. libquadmath which
may or may not be available on the target, and can be explicitly
enabled/disabled at configure time etc.

[Bug fortran/54572] Use libbacktrace library

[ian at airs dot com]

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

--- Comment #14 from Ian Lance Taylor <ian at airs dot com> 2012-12-01 06:43:07 UTC ---
Thanks for the additional info.

#1  0x00007ffff7bb53be in build_address_map (addrs=0x7fffffffc710,
data=0x7fffffffcf1c, 
    error_callback=0x7ffff7ad51f0 <error_callback>, is_bigendian=0,
dwarf_str_size=360, 
    dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_ranges_size=0, 
    dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>,
dwarf_abbrev_size=253, 
    dwarf_abbrev=0x7ffff7ff708f
"\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", 
    dwarf_info_size=484, dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out
of bounds>, 
    base_address=<optimized out>, state=<optimized out>) at
../../../trunk-git/libbacktrace/dwarf.c:1299

That is weird because it is showing the parameters in reverse order.  Is that
what gdb normally does on your system?  It doesn't seem to do it for other
functions.

Here gdb says that the value of dwarf_info is out of bounds.  That is not good.
 That is most likely the immediate cause of the problem.  (dwarf_ranges is also
out of bounds, but that likely doesn't matter as dwarf_ranges_size is zero.)

It looks like it had trouble getting the debug info for the executable file
itself.  Can you add the output of readelf -S on the executable?

[Bug fortran/54572] Use libbacktrace library

[jb at gcc dot gnu.org]

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

--- Comment #15 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-12-01 19:48:12 UTC ---
(In reply to comment #14)
> Thanks for the additional info.
> 
> #1  0x00007ffff7bb53be in build_address_map (addrs=0x7fffffffc710,
> data=0x7fffffffcf1c, 
>     error_callback=0x7ffff7ad51f0 <error_callback>, is_bigendian=0,
> dwarf_str_size=360, 
>     dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_ranges_size=0, 
>     dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>,
> dwarf_abbrev_size=253, 
>     dwarf_abbrev=0x7ffff7ff708f
> "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", 
>     dwarf_info_size=484, dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out
> of bounds>, 
>     base_address=<optimized out>, state=<optimized out>) at
> ../../../trunk-git/libbacktrace/dwarf.c:1299
> 
> That is weird because it is showing the parameters in reverse order.  Is that
> what gdb normally does on your system?  It doesn't seem to do it for other
> functions.

No, I've never seen it before. Then again, before yesterday I had never used
GDB 7.5, only older versions.

> Here gdb says that the value of dwarf_info is out of bounds.  That is not good.
>  That is most likely the immediate cause of the problem.  (dwarf_ranges is also
> out of bounds, but that likely doesn't matter as dwarf_ranges_size is zero.)
> 
> It looks like it had trouble getting the debug info for the executable file
> itself.  Can you add the output of readelf -S on the executable?

$ readelf -S bt2.g
There are 35 section headers, starting at offset 0x1668:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000000400200  00000200
       000000000000001c  0000000000000000   A       0     0     1
  [ 2] .note.ABI-tag     NOTE             000000000040021c  0000021c
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .hash             HASH             0000000000400240  00000240
       0000000000000040  0000000000000004   A       4     0     8
  [ 4] .dynsym           DYNSYM           0000000000400280  00000280
       0000000000000108  0000000000000018   A       5     1     8
  [ 5] .dynstr           STRTAB           0000000000400388  00000388
       00000000000001c8  0000000000000000   A       0     0     1
  [ 6] .gnu.version      VERSYM           0000000000400550  00000550
       0000000000000016  0000000000000002   A       4     0     2
  [ 7] .gnu.version_r    VERNEED          0000000000400568  00000568
       0000000000000050  0000000000000000   A       5     2     8
  [ 8] .rela.dyn         RELA             00000000004005b8  000005b8
       0000000000000018  0000000000000018   A       4     0     8
  [ 9] .rela.plt         RELA             00000000004005d0  000005d0
       0000000000000090  0000000000000018   A       4    11     8
  [10] .init             PROGBITS         0000000000400660  00000660
       000000000000000e  0000000000000000  AX       0     0     4
  [11] .plt              PROGBITS         0000000000400670  00000670
       0000000000000070  0000000000000010  AX       0     0     16              
  [12] .text             PROGBITS         00000000004006e0  000006e0            
       00000000000002f4  0000000000000000  AX       0     0     16              
  [13] .fini             PROGBITS         00000000004009d4  000009d4            
       0000000000000009  0000000000000000  AX       0     0     4               
  [14] .rodata           PROGBITS         00000000004009e0  000009e0            
       000000000000003c  0000000000000000   A       0     0     16              
  [15] .eh_frame_hdr     PROGBITS         0000000000400a1c  00000a1c            
       000000000000004c  0000000000000000   A       0     0     4               
  [16] .eh_frame         PROGBITS         0000000000400a68  00000a68            
       0000000000000124  0000000000000000   A       0     0     8               
  [17] .init_array       INIT_ARRAY       0000000000600b90  00000b90            
       0000000000000008  0000000000000000  WA       0     0     8               
  [18] .fini_array       FINI_ARRAY       0000000000600b98  00000b98
       0000000000000008  0000000000000000  WA       0     0     8
  [19] .jcr              PROGBITS         0000000000600ba0  00000ba0
       0000000000000008  0000000000000000  WA       0     0     8
  [20] .dynamic          DYNAMIC          0000000000600ba8  00000ba8
       0000000000000220  0000000000000010  WA       5     0     8
  [21] .got              PROGBITS         0000000000600dc8  00000dc8
       0000000000000008  0000000000000008  WA       0     0     8
  [22] .got.plt          PROGBITS         0000000000600dd0  00000dd0
       0000000000000048  0000000000000008  WA       0     0     8
  [23] .data             PROGBITS         0000000000600e18  00000e18
       0000000000000010  0000000000000000  WA       0     0     8
  [24] .bss              NOBITS           0000000000600e28  00000e28
       0000000000000008  0000000000000000  WA       0     0     4
  [25] .comment          PROGBITS         0000000000000000  00000e28
       0000000000000053  0000000000000001  MS       0     0     1
  [26] .debug_aranges    PROGBITS         0000000000000000  00000e7b
       0000000000000030  0000000000000000           0     0     1
  [27] .debug_info       PROGBITS         0000000000000000  00000eab
       00000000000001e4  0000000000000000           0     0     1
  [28] .debug_abbrev     PROGBITS         0000000000000000  0000108f
       00000000000000fd  0000000000000000           0     0     1
  [29] .debug_line       PROGBITS         0000000000000000  0000118c
       0000000000000057  0000000000000000           0     0     1
  [30] .debug_str        PROGBITS         0000000000000000  000011e3
       0000000000000168  0000000000000001  MS       0     0     1
  [31] .debug_loc        PROGBITS         0000000000000000  0000134b
       00000000000001e0  0000000000000000           0     0     1
  [32] .shstrtab         STRTAB           0000000000000000  0000152b
       000000000000013c  0000000000000000           0     0     1
  [33] .symtab           SYMTAB           0000000000000000  00001f28
       0000000000000768  0000000000000018          34    52     8
  [34] .strtab           STRTAB           0000000000000000  00002690
       000000000000032d  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


Like I mentioned previously, my binutils is version 2.22 which apparently
doesn't have complete support for DWARF-4. I can certainly try upgrading, if
you think that would help; I don't really know what to look for in the above
output, sorry.

[Bug libfortran/54572] Use libbacktrace library

[fxcoudert at gcc dot gnu.org]

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

--- Comment #16 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Patch proposed: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00762.html

[Bug libfortran/54572] Use libbacktrace library

[fxcoudert at gcc dot gnu.org]

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

--- Comment #17 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Author: fxcoudert
Date: Sun Aug 23 21:50:30 2015
New Revision: 227106

URL: https://gcc.gnu.org/viewcvs?rev=227106&root=gcc&view=rev
Log:
        PR libfortran/54572

        * Makefile.def: Make libgfortran depend on libbacktrace.
        * Makefile.in: Regenerate.

        * config-lang.in: Add libbacktrace to target_libs.

        * Makefile.am (libgfortran_la_LDFLAGS): Link in libbacktrace.
        (AM_CPPFLAGS): Add libbacktrace directories to include paths.
        * Makefile.in: Regenerate.
        * aclocal.m4: Regenerate.
        * config.h.in: Regenerate.
        * configure: Regenerate.
        * configure.ac: Remove checks for strtok_r, wait, execve, pipe,
        and dup2. Remove call to GCC_CHECK_UNWIND_GETIPINFO.
        * libgfortran.h (full_exe_path, find_addr2line, backtrace): Remove
        prototypes.
        (show_backtrace): Add prototype.
        * runtime/backtrace.c: Rework file entirely.
        * runtime/compile_options.c (backtrace_handler): Rename backtrace
        to show_backtrace.
        (maybe_find_addr2line): Remove function.
        (set_options): Remove call to maybe_find_addr2line.
        * runtime/error.c (sys_abort): Rename backtrace to show_backtrace.
        * runtime/main.c (store_exe_path): Empty function body.
        (full_exe_path, gfstrtok_r, find_addr2line): Remove functions.
        (cleanup): Don't free removed variables.
        * runtime/minimal.c (full_exe_path): Remove function.
        (set_args): Don't set exe_path.

        * gfortran.dg/backtrace_1.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/backtrace_1.f90
Modified:
    trunk/ChangeLog
    trunk/Makefile.def
    trunk/Makefile.in
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/config-lang.in
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/Makefile.am
    trunk/libgfortran/Makefile.in
    trunk/libgfortran/aclocal.m4
    trunk/libgfortran/config.h.in
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac
    trunk/libgfortran/libgfortran.h
    trunk/libgfortran/runtime/backtrace.c
    trunk/libgfortran/runtime/compile_options.c
    trunk/libgfortran/runtime/error.c
    trunk/libgfortran/runtime/main.c
    trunk/libgfortran/runtime/minimal.c

[Bug libfortran/54572] Use libbacktrace library

[fxcoudert at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0

--- Comment #18 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Fixed on trunk.