0

I took the advice that is given in the comments of this question Gfortran does not tell me what sort of FPE it is i.e. start up GDB , set a breakpoint to that line and inspect the values of the operation. At the outset my program is based on Fortran 77 code(I plan to migrate it to F90 after running this "test case" an idealistic CFD data test) and uses NetCDF shared libraries on Ubuntu 16.04 LTS. I use the gfortran 4.8.5 compiler(can upgrade to 5.x if required).

This is how the program is compiled

gfortran -Wall -O0 -c -g -fbacktrace -ffpe-trap=invalid,denormal,zero,overflow,underflow ${tool}.f ${ncdf_incs}

Now I started gdb in the directory where the program is located and then I typed

break inv_cart.f:1221

which is where the FPE is occurring(a divide by zero error). When I do this I get this message -

  Make breakpoint based on future shared library load (y/n) ?

So I searched SO for this problem and I got this previously Q/A - How to set breakpoints with shared libraries and this is what I did

set breakpoint pending on
break inv_cart.f:1221

UPDATE

I had an oversight. After I run break I get this error message

No symbol table is loaded. Use the "file" command
Breakpoint 1 (inv_cart.f:1221) is pending. 

END UPDATE

After I do this I get the same error I got when I ran inv_cart within gdb or as stand alone.

Program received signal SIGFPE - arithmetic exception

followed by a memory address and couple of question marks followed by (). So I quit gdb and then it tells me that there is a a debugging session that is still active.

So my question still remains - How do I obtain the values where the FPE is occurring ?

gansub
  • 1,164
  • 3
  • 20
  • 47
  • 1
    Make breakpoint based on future shared library load (y/n) ? - This suggests to me that the GDB instance does not have sufficient knowledge of the source code to know where to set the break point, and therefore, rather than pausing execution at inv_cart.f:1221, it is instead continuing to run (and consequently hitting your FPE). Could you provide additional information about what compiler flags you are using for this work. Try removing any optimization (-O#) and including the -g (EDIT - Read the linked Q, and see you have the right flags already) - the issue with not finding src is still valid. – Silasvb Jul 06 '17 at 11:38
  • @s8129 - that information about compilation has been added to the question. – gansub Jul 06 '17 at 11:41
  • @s8129 - not sure how NetCDF shared libraries affect this problem. The FPE and the shared library have no connection – gansub Jul 06 '17 at 11:43
  • Is the source code in the same directory as the executable? If not, try adding -d "PATH TO SRC" if not. – Silasvb Jul 06 '17 at 11:45
  • @s8129 - Yes it is in the same directory. – gansub Jul 06 '17 at 11:47
  • 1
    That command is not compiling the program -- only that file. (The `-c` option tells it not to invoke the linker.) Make sure you are using the -g option in compiling ALL source files and in the linking stage. – Jack Jul 06 '17 at 13:59

1 Answers1

1

This is a straightforward problem after the update has been noticed by me.

I looked up this question - gdb no symbol table is loaded and I went ahead and did this

file inv_cart 

and finally the symbol table was loaded and to my joy I ran the program again via gdb and was able to print the value of the piece of code where the FPE was occurring.

gansub
  • 1,164
  • 3
  • 20
  • 47