Obtaining backtrace with symbols after SIGSEGV from gfortran application

Question

I'm compiling with gfortran 4.8.1 with the flags -ggdb -O0 -Wall -Wextra -Wtabs -Wsurprising -fbacktrace -fimplicit-none -fcheck=all -std=f2008. Running in gdb I get a backtrace with no procedure names:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000100000000 in ?? ()
#2  0x00007fffffffd760 in ?? ()
#3  0x3f1a36e2eb1c432d in ?? ()
#4  0x3da5fd7fe1796495 in ?? ()
#5  0x4024000000000000 in ?? ()
#6  0x3eb0c6f7a0b5ed8d in ?? ()
#7  0x408f400000000000 in ?? ()
#8  0x408f400000000000 in ?? ()
#9  0x0000000000000000 in ?? ()

After executing ./gyre, which segfaults, I invoke gdb ./gyre core. I see a warning Can't read pathname for load map: Input/output error, but I'm not sure if that's relevant to the problem.

What do I need to do to see where the SIGSEGV occurred?

Update: So I suspect the stack corruption must be related to a procedure point initialisation, since my code was not segfaulting prior to this change. I'm not able to provide the full source code, but the relevant snippet is

pure function new_default_sim_spec() result(spec)
    type(sim_spec_type)  :: spec

    spec = new_sim_spec(1.0_dp)
end function new_default_sim_spec

pure function new_sim_spec(max_days) result(spec)
    type(sim_spec_type)  :: spec
    real(dp), intent(in) :: max_days

    ! snipped other attribute assignments
    spec%increment_h => increment_h_euler
end function new_sim_spec

abstract interface
    pure function increment_h_iface(spec, state_minus_1) result(state)
        import                              :: sim_state_type, sim_spec_type
        type(sim_state_type)                :: state

        class(sim_spec_type), intent(in)    :: spec
        type(sim_state_type), intent(in)    :: state_minus_1
    end function increment_h_iface
end interface

type sim_spec_type
    ! snipped other attribute declarations
    procedure(increment_h_iface), pointer   :: increment_h => null()
end type sim_spec_type

Answer 1

Running in gdb I get a backtrace with no procedure names:

How did you run GDB?

I am guessing you did gdb /path/to/core. Try gdb /path/to/executable /path/to/core instead.

Update:

gdb ./gyre core. I see a warning ...

That warning is irrelevant (and frequently there, though I don't understand the exact conditions which trigger it).

The other obvious way to check where SIGSEGV occurred is to simply run the binary under GDB from the start. You don't need to wait for core, a simple:

gdb ./gyre
(gdb) run

should suffice.

Update 2:

I've tried running the program itself under gdb and have the same problem. I see plenty of expected function names listed by nm so the binary cannot have been stripped.

This implies either:

• some kind of non-standard setting in ~/.gdbinit, or
• a bug in GDB.

To eliminate the former, try gdb -nx ./gyre.

For the latter, try a different version of GDB, or make the binary available somewhere and I can take a look.

Update 3:

The reason GDB can't produce a stack trace is that your stack is getting corrupted on line simulation.f90:45:

(gdb) bt
#0  simulation::new_default_sim_spec () at simulation.f90:45
#1  0x0000000000401054 in gyre () at gyre.f90:21
#2  0x0000000000401fad in main (argc=1, argv=0x7fffffffeb24) at gyre.f90:3
#3  0x00007ffff742876d in __libc_start_main (main=0x401f79 <main>, argc=1, ubp_av=0x7fffffffe878, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe868) at libc-start.c:226
#4  0x0000000000400be9 in _start ()

(gdb) n
41  in simulation.f90

(gdb) bt
#0  simulation::new_default_sim_spec () at simulation.f90:41
#1  0x0000000000000000 in ?? ()

Notice how before line 45 the stack is good, but after it's not. The particular instruction that "wipes" the stack is this one:

=> 0x408fde <__simulation_MOD_new_default_sim_spec+93>: movq   $0x0,0x8(%rbp)

Without access to your sources, and with 20 years since I last touched Fortran, I can't make an intelligent guess at what kind of Fortran code could provoke such a bug.

Answer 2

Newer gcc versions default to dwarf-4 format debug info. If you have an older toolchain it might not understand it. Try -gdwarf-2.