traceback

[dajum]

I'm running the same program on windows and linux. I get a nice traceback on windows which gives the line number 895 in astap.for

forrtl: error (73): floating divide by zero

Image PC Routine Line Source

astap.exe 00000001400014AA MAIN__ 895 astap.for

astap.exe 0000000140384C4C Unknown Unknown Unknown

astap.exe 0000000140373F4B Unknown Unknown Unknown

kernel32.dll 000000007722F56D Unknown Unknown Unknown

ntdll.dll 0000000077363281 Unknown Unknown Unknown

On linux I'm getting
/home/dajum/SFInstall/bin/sindad: line 112: 16515 Floating point exception./astap ${sinda85_keep_dir}/"$1".messages.log 1
where line 112 is in the script file that executes the code. It doesn't even have the same type of error which I know is a divide by zero. My compilation flags are:

DEBUG= -O3

FC=ifort

FFLAGS= $(DEBUG) -fpe0 -traceback -extend-source -real-size 64 -integer-size 64 -names lowercase -I../include/fluint -I../include -assume byterecl

Is there something missing here?

[mecej4]

Using "DEBUG= -O3" is not conducive to correlating errors to line-numbers. This is not a reasonable options to use for debugging, unless you are engaged in debugging the operation of the compiler itself rather than your program.

Try "DEBUG = -g" instead.

[dajum]

This is a release build so I do want optimization. It works fine on windows. As I understand it the traceback doesn't require -g.

[Steven_L_Intel1]

Traceback indeed does not depend on debug info.

What happens if you run the program from a terminal window rather than a script?

[dajum]

it just lists "Floating point exception".

[Steven_L_Intel1]

Interesting. Here's what I get:

[sblionel@f90srv17 ~/project]$ ifort -traceback -fpe0 t.f90
[sblionel@f90srv17 ~/project]$ ./a.out
0
forrtl: error (73): floating divide by zero
Image PC Routine Line Source
a.out 08049DB0 MAIN__ 3 t.f90
a.out 08049D14 Unknown Unknown Unknown
libc.so.6 005F4E9C Unknown Unknown Unknown
a.out 08049C01 Unknown Unknown Unknown
Abort

[dajum]

I can do trivial examples and they all work fine too. But a nice complex mixed-language program fails, hard to know why. Boiling it down to sample I can send in is always a huge effort. It is probably related to my questions on IO.

[dajum]

I hit different execption in another model. It did give a traceback, so it appear it will work for some issues.

forrtl: Bad address

forrtl: severe (39): error during read, unit 16, file /home/tmp/dajum20179/CNTDAT

Image PC Routine Line Source

astap 0000000000838BBA Unknown Unknown Unknown

astap 0000000000837735 Unknown Unknown Unknown

astap 00000000007F6CC6 Unknown Unknown Unknown

astap 00000000007A4F85 Unknown Unknown Unknown

astap 00000000007A4741 Unknown Unknown Unknown

astap 00000000007C34F7 Unknown Unknown Unknown

astap 00000000007C1AB7 Unknown Unknown Unknown

astap 000000000059CE6C rdcntr_ 75 rdcntr.f

astap 000000000041B1D9 readin_ 67 readin.f

astap 0000000000409995 MAIN__ 925 astap.F

astap 000000000040971C Unknown Unknown Unknown

libc.so.6 0000003E4F81D994 Unknown Unknown Unknown

astap 0000000000409629 Unknown Unknown Unknown

[Steven_L_Intel1]

Are you sure that the exception is happening in Fortran code? If you can come up with a smaller test case, that would be great.

[dajum]

Yes it is in fortran. The line is b = 10/a where a=0.0

It is also very interesting to note that a line further down with seems to compile without error or warning is
a = b +++ c

and is just treated as a = b+c

Must be treating it as multiple uniary operators.

[Steven_L_Intel1]

Yes, we support that as an extension.