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..
