* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
@ 2012-09-15 11:26 ` hp at gcc dot gnu.org
2012-09-16 8:33 ` jb at gcc dot gnu.org
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hp at gcc dot gnu.org @ 2012-09-15 11:26 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
2012-09-15 11:26 ` [Bug fortran/54572] " hp at gcc dot gnu.org
@ 2012-09-16 8:33 ` jb at gcc dot gnu.org
2012-09-16 23:16 ` hp at gcc dot gnu.org
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jb at gcc dot gnu.org @ 2012-09-16 8:33 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
2012-09-15 11:26 ` [Bug fortran/54572] " hp at gcc dot gnu.org
2012-09-16 8:33 ` jb at gcc dot gnu.org
@ 2012-09-16 23:16 ` hp at gcc dot gnu.org
2012-11-25 15:10 ` jb at gcc dot gnu.org
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hp at gcc dot gnu.org @ 2012-09-16 23:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2012-09-16 23:16 ` hp at gcc dot gnu.org
@ 2012-11-25 15:10 ` jb at gcc dot gnu.org
2012-11-26 16:43 ` jb at gcc dot gnu.org
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jb at gcc dot gnu.org @ 2012-11-25 15:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (3 preceding siblings ...)
2012-11-25 15:10 ` jb at gcc dot gnu.org
@ 2012-11-26 16:43 ` jb at gcc dot gnu.org
2012-11-26 16:46 ` jb at gcc dot gnu.org
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jb at gcc dot gnu.org @ 2012-11-26 16:43 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (4 preceding siblings ...)
2012-11-26 16:43 ` jb at gcc dot gnu.org
@ 2012-11-26 16:46 ` jb at gcc dot gnu.org
2012-11-26 23:03 ` ian at airs dot com
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jb at gcc dot gnu.org @ 2012-11-26 16:46 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (5 preceding siblings ...)
2012-11-26 16:46 ` jb at gcc dot gnu.org
@ 2012-11-26 23:03 ` ian at airs dot com
2012-11-26 23:09 ` ian at airs dot com
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ian at airs dot com @ 2012-11-26 23:03 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (6 preceding siblings ...)
2012-11-26 23:03 ` ian at airs dot com
@ 2012-11-26 23:09 ` ian at airs dot com
2012-11-27 8:59 ` jb at gcc dot gnu.org
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ian at airs dot com @ 2012-11-26 23:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (7 preceding siblings ...)
2012-11-26 23:09 ` ian at airs dot com
@ 2012-11-27 8:59 ` jb at gcc dot gnu.org
2012-11-27 9:33 ` burnus at gcc dot gnu.org
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jb at gcc dot gnu.org @ 2012-11-27 8:59 UTC (permalink / raw)
To: gcc-bugs
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..
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (8 preceding siblings ...)
2012-11-27 8:59 ` jb at gcc dot gnu.org
@ 2012-11-27 9:33 ` burnus at gcc dot gnu.org
2012-11-27 10:06 ` burnus at gcc dot gnu.org
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-11-27 9:33 UTC (permalink / raw)
To: gcc-bugs
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; };
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (9 preceding siblings ...)
2012-11-27 9:33 ` burnus at gcc dot gnu.org
@ 2012-11-27 10:06 ` burnus at gcc dot gnu.org
2012-11-30 21:56 ` jb at gcc dot gnu.org
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-11-27 10:06 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (10 preceding siblings ...)
2012-11-27 10:06 ` burnus at gcc dot gnu.org
@ 2012-11-30 21:56 ` jb at gcc dot gnu.org
2012-11-30 22:03 ` jb at gcc dot gnu.org
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jb at gcc dot gnu.org @ 2012-11-30 21:56 UTC (permalink / raw)
To: gcc-bugs
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..
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (11 preceding siblings ...)
2012-11-30 21:56 ` jb at gcc dot gnu.org
@ 2012-11-30 22:03 ` jb at gcc dot gnu.org
2012-12-01 6:43 ` ian at airs dot com
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jb at gcc dot gnu.org @ 2012-11-30 22:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (12 preceding siblings ...)
2012-11-30 22:03 ` jb at gcc dot gnu.org
@ 2012-12-01 6:43 ` ian at airs dot com
2012-12-01 19:48 ` jb at gcc dot gnu.org
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ian at airs dot com @ 2012-12-01 6:43 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug fortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (13 preceding siblings ...)
2012-12-01 6:43 ` ian at airs dot com
@ 2012-12-01 19:48 ` jb at gcc dot gnu.org
2015-08-14 8:33 ` [Bug libfortran/54572] " fxcoudert at gcc dot gnu.org
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jb at gcc dot gnu.org @ 2012-12-01 19:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug libfortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (14 preceding siblings ...)
2012-12-01 19:48 ` jb at gcc dot gnu.org
@ 2015-08-14 8:33 ` fxcoudert at gcc dot gnu.org
2015-08-23 21:51 ` fxcoudert at gcc dot gnu.org
2015-08-23 21:52 ` fxcoudert at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-08-14 8:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug libfortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (15 preceding siblings ...)
2015-08-14 8:33 ` [Bug libfortran/54572] " fxcoudert at gcc dot gnu.org
@ 2015-08-23 21:51 ` fxcoudert at gcc dot gnu.org
2015-08-23 21:52 ` fxcoudert at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-08-23 21:51 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug libfortran/54572] Use libbacktrace library
2012-09-13 22:26 [Bug fortran/54572] New: Use libbacktrace library burnus at gcc dot gnu.org
` (16 preceding siblings ...)
2015-08-23 21:51 ` fxcoudert at gcc dot gnu.org
@ 2015-08-23 21:52 ` fxcoudert at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-08-23 21:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread