CODEWITHSUNDEEP
debugginggfortranbacktrace
Beata
Beata

Reputation: 355

Why gfortran does not give symbolic backtrace?

After I ran my fortran code with gfortran compiler using with –g otion I get the following error:

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

Backtrace for this error:
#0  0x7F2EE30E57D7
#1  0x7F2EE30E5DDE
#2  0x7F2EE2820D3F
#3  0x7F2EE2DEC913
#4  0x408A97 in __aerosols_MOD_moment_logn at aerosols.f90:45
#5  0x408A02 in __aerosols_MOD_set_aerosol at aerosols.f90:78 (discriminator 20)
#6  0x6D357B in __test_cases_2d_MOD_standard_2d_cases at test_cases_2d.f90:210
#7  0x67E9FC in __set_profiles_MOD_read_profiles_standard at set_profiles.f90:118
#8  0x463BF8 in __main_MOD_main_loop at main.f90:48
#9  0x401F05 in kid at KiD.f90:17
Floating point exception (core dumped)

I do not understand why the first four backtraces does not inform about the error trace. I tried addr2line to find the address but it also does not give information. How can I get to know the error traces?

Upvotes: 2

Views: 4166

Answers (3)

janneb
janneb

Reputation: 37228

The symbolic backtraces printed by gfortran are not done by gdb, but rather by addr2line. The problem is that addr2line inspects the binary on disk and not the program image in memory. Thus for shared libraries, which are loaded into memory at some random offset (for security reasons), addr2line cannot translate the addresses into symbol names and thus the gfortran backtrace mechanism falls back to printing the addresses.

You can work around this by compiling statically, allowing addr2line to translate addresses in libgfortran, the gfortran runtime library. Usually the first few stack frames are from the libgfortran backtrace printing functionality, in any case.

Upvotes: 2

Employed Russian
Employed Russian

Reputation: 213799

I do not understand why the first four backtraces does not inform about the error trace.

The stack trace you got is from some kind of internal Fortran error reporting mechanism, and not from GDB as your question implies. That mechanism is likely not handling shared libraries (note that all the "missing" frames are very far from application frames -- the missing frames are likely in a shared library).

Solution: run the program under GDB, and use where command. GDB knows how to read symbol info for shared libraries, and is likely to give you the missing info.

Upvotes: 1

Tom Tromey
Tom Tromey

Reputation: 22549

There are a few ways you can wind up with some stack frames that don't have useful information.

One way is if your program has a bug and trashes the stack. In this case I would suggest turning to valgrind to find the problem.

Another way is if the code in question was compiled without debuginfo. Sometimes you may still get some information here, but not always. In this case the solution is to recompile the code with -g.

A third way is if your program contains a just-in-time compiler and the execution stops in JITted code. I suspect this isn't your issue, given that you're working in FORTRAN.

One way to tell where the code may have come from is to use info shared or info proc mappings, and search though the list of addresses to see where the PC values from the offending frames fit it. (Yes, it's unfortunate to do this by hand.) If the PC fits into one of the maps listed, then you know where to look to fix the -g problem. If it doesn't fit anywhere, then most likely the stack is trashed.

Upvotes: 0

Related Questions