[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #15 from Janne Blomqvist 2012-12-01
19:48:12 UTC ---
(In reply to comment #14)
> Thanks for the additional info.
>
> #1 0x77bb53be in build_address_map (addrs=0x7fffc710,
> data=0x7fffcf1c,
> error_callback=0x77ad51f0 , is_bigendian=0,
> dwarf_str_size=360,
> dwarf_str=0x77ff71e3 "integer(kind=4)", dwarf_ranges_size=0,
> dwarf_ranges=0x77ff6000 ,
> dwarf_abbrev_size=253,
> dwarf_abbrev=0x77ff708f
> "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006",
> dwarf_info_size=484, dwarf_info=0x77ff6eab of bounds>,
> base_address=, state=) 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
0 0 0
[ 1] .interp PROGBITS 00400200 0200
001c A 0 0 1
[ 2] .note.ABI-tag NOTE 0040021c 021c
0020 A 0 0 4
[ 3] .hash HASH 00400240 0240
0040 0004 A 4 0 8
[ 4] .dynsym DYNSYM 00400280 0280
0108 0018 A 5 1 8
[ 5] .dynstr STRTAB 00400388 0388
01c8 A 0 0 1
[ 6] .gnu.version VERSYM 00400550 0550
0016 0002 A 4 0 2
[ 7] .gnu.version_rVERNEED 00400568 0568
0050 A 5 2 8
[ 8] .rela.dyn RELA 004005b8 05b8
0018 0018 A 4 0 8
[ 9] .rela.plt RELA 004005d0 05d0
0090 0018 A 411 8
[10] .init PROGBITS 00400660 0660
000e AX 0 0 4
[11] .plt PROGBITS 00400670 0670
0070 0010 AX 0 0 16
[12] .text PROGBITS 004006e0 06e0
02f4 AX 0 0 16
[13] .fini PROGBITS 004009d4 09d4
0009 AX 0 0 4
[14] .rodata PROGBITS 004009e0 09e0
003c A 0 0 16
[15] .eh_frame_hdr PROGBITS 00400a1c 0a1c
004c A 0 0 4
[16] .eh_frame PROGBITS 00400a68 0a68
0124 A 0 0 8
[17] .init_array INIT_ARRAY 00600b90 0b90
0008 WA 0 0 8
[18] .fini_array FINI_ARRAY 00600b98 0b98
0008 WA 0 0 8
[19] .jcr PROGBITS 00600ba0 0ba0
0008 WA 0 0 8
[20] .dynamic DYNAMIC 00600ba8 0ba8
0220 0010 WA 5 0 8
[21] .got PROGBITS 00600dc8 0dc8
0008 0008 WA 0 0 8
[22] .got.plt PROGBITS 00600dd0 0dd0
0048 0008 WA
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #14 from Ian Lance Taylor 2012-12-01 06:43:07 UTC --- Thanks for the additional info. #1 0x77bb53be in build_address_map (addrs=0x7fffc710, data=0x7fffcf1c, error_callback=0x77ad51f0 , is_bigendian=0, dwarf_str_size=360, dwarf_str=0x77ff71e3 "integer(kind=4)", dwarf_ranges_size=0, dwarf_ranges=0x77ff6000 , dwarf_abbrev_size=253, dwarf_abbrev=0x77ff708f "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", dwarf_info_size=484, dwarf_info=0x77ff6eab , base_address=, state=) 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #13 from Janne Blomqvist 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #12 from Janne Blomqvist 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. 0x0040086b 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=0x7fffc730) 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=0x7fffc730) at ../../../trunk-git/libbacktrace/dwarf.c:458 #1 0x77bb53be in build_address_map (addrs=0x7fffc710, data=0x7fffcf1c, error_callback=0x77ad51f0 , is_bigendian=0, dwarf_str_size=360, dwarf_str=0x77ff71e3 "integer(kind=4)", dwarf_ranges_size=0, dwarf_ranges=0x77ff6000 , dwarf_abbrev_size=253, dwarf_abbrev=0x77ff708f "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", dwarf_info_size=484, dwarf_info=0x77ff6eab , base_address=, state=) at ../../../trunk-git/libbacktrace/dwarf.c:1299 #2 build_dwarf_data (data=0x7fffcf1c, error_callback=0x77ad51f0 , is_bigendian=0, dwarf_str_size=360, dwarf_str=0x77ff71e3 "integer(kind=4)", dwarf_ranges_size=0, dwarf_ranges=0x77ff6000 , dwarf_abbrev_size=253, dwarf_abbrev=0x77ff708f "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", dwarf_line_size=, dwarf_line=, dwarf_info_size=484, dwarf_info=0x77ff6eab , base_address=, state=) at ../../../trunk-git/libbacktrace/dwarf.c:2822 #3 backtrace_dwarf_add (state=state@entry=0x77ff8000, base_address=base_address@entry=0, dwarf_info=0x77ff6eab , dwarf_info_size=484, dwarf_line=0x77ff718c "S", dwarf_line_size=87, dwarf_abbrev=0x77ff708f "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", dwarf_abbrev_size=253, dwarf_ranges=0x77ff6000 , dwarf_ranges_size=0, dwarf_str=0x77ff71e3 "integer(kind=4)", dwarf_str_size=360, is_bigendian=0, error_callback=error_callback@entry=0x77ad51f0 , data=data@entry=0x7fffcf1c, fileline_fn=fileline_fn@entry=0x7fffcb18) at ../../../trunk-git/libbacktrace/dwarf.c:2881 #4 0x77bb72a7 in elf_add (state=state@entry=0x77ff8000, descriptor=, base_address=base_address@entry=0, error_callback=error_callback@entry=0x77ad51f0 , data=data@entry=0x7fffcf1c, fileline_fn=fileline_fn@entry=0x7fffcb18, found_sym=found_sym@entry=0x7fffcb10, found_dwarf=found_dwarf@entry=0x7fffcb14) at ../../../trunk-git/libbacktrace/elf.c:757 #5 0x77bb7696 in backtrace_initialize (state=state@entry=0x77ff8000, descriptor=, error_callback=error_callback@entry=0x77ad51f0 , data=data@entry=0x7fffcf1c, fileline_fn=fileline_fn@entry=0x7fffcb98) at ../../../trunk-git/libbacktrace/elf.c:858 #6 0x77bb630d in fileline_initialize (state=state@entry=0x77ff8000, error_callback=error_callback@entry=0x77ad51f0 , data=data@entry=0x7fffcf1c) at ../../../trunk-git/libbacktrace/fileline.c:144 #7 0x77bb6427 in backtrace_pcinfo (state=0x77ff8000, pc=140737348719229, callback=0x77ad5170 , error_callback=0x77ad51f0 , data=0x7fffcf1c) at ../../../trunk-git/libbacktrace/fileline.c:184 #8 0x77bb6831 in unwind (context=, vdata=0x7fffced0) at ../../../trunk-git/libbacktrace/backtrace.c:83 #9 0x775b9f49 in _Unwind_Backtrace (trace=trace@entry=0x77bb67e0 , trace_argument=trace_argument@entry=0x7fffced0) at ../../../trunk-git/libgcc/unwind.inc:295 #10 0x77bb6885 in backtrace_full (state=state@entry=0x77ff8000, skip=skip@entry=0, callback=callback@entr
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #10 from Tobias Burnus 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #9 from Janne Blomqvist 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #8 from Ian Lance Taylor 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #7 from Ian Lance Taylor 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #6 from Janne Blomqvist 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Janne Blomqvist changed: What|Removed |Added CC||ian at airs dot com --- Comment #5 from Janne Blomqvist 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. 0x0040086b 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. 0x77bb2a1c in read_uint32 () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 (gdb) bt #0 0x77bb2a1c in read_uint32 () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #1 0x77bb53be in backtrace_dwarf_add () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #2 0x77bb72a7 in elf_add () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #3 0x77bb7696 in backtrace_initialize () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #4 0x77bb630d in fileline_initialize () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #5 0x77bb6427 in backtrace_pcinfo () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #6 0x77bb6831 in unwind () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #7 0x775b9ec9 in _Unwind_Backtrace () from /home/janne/src/gfortran/trunk/install/lib64/libgcc_s.so.1 #8 0x77bb6885 in backtrace_full () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #9 0x77ad527e in _gfortrani_show_backtrace () at ../../../trunk-git/libgfortran/runtime/backtrace.c:92 #10 0x77ad5888 in _gfortrani_backtrace_handler () at ../../../trunk-git/libgfortran/runtime/compile_options.c:129 #11 #12 0x0040086b in __test_MOD_c () #13 0x00400848 in __test_MOD_b () #14 0x0040081b in __test_MOD_a () #15 0x00400898 in MAIN__ () #16 0x00400930 in main () #17 0x76fd176d in __libc_start_main (main=0x4008fc , argc=1, ubp_av=0x7fffd718, init=, fini=, rtld_fini=, stack_end=0x7fffd708) at libc-start.c:226 #18 0x00400709 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Janne Blomqvist 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #3 from Hans-Peter Nilsson 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #2 from Janne Blomqvist 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson 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.)
