Why does the error message point to the wrong source line?

[Dogbite]

When I first got the "forrtl: error (72) floating overflow" message, the address on top of the call stack was line 221 in the routine SAFETY.FOR. A look at the program's status output indicated that the error occurred during the second loop through the sections and the last section to complete processing was number 98761. So immediately above line 229 Iadded an IF construct ("is it second loop and section number 98762")containing some print statements.

Nothing. Same error and message (now line number 229), 98761 the last section processed, but no output from my print statements.

I modify the IF construct to print for all section during the second loop, and get output for many sections. The last section I get output from is 98754. The last section processed is again 98761, and the error message still points to line 229, but no output for section 98762.

The equation pointed to on line 229 is on one of six or seven paths through the routine. I add another IF construct ("if second loop") to print out the parameters that determine which path is followed. The output I get now includes section 98762 and indicates that it would not follow a path to execute the line identified by the earlier error messages -- suggesting that the error handler has mis-identified the line generating the error.

Oh, and the error message (still fp overflow) now points to the first line of the new set of print statements, the one that prints out a blank line. What's going on here?

[Steven_L_Intel1]

Without seeing an example, I can suggest the following:

• If the program was compiled with optimization, there may not be a straightforward correlation between PC and line number
• By default, floating point exceptions are "imprecise" in that several more instructions may have executed before the error is reported. Try using /fp:except to see if the behavior changes.

[Dogbite]

Quoting - Steve Lionel (Intel)

Without seeing an example, I can suggest the following:

• If the program was compiled with optimization, there may not be a straightforward correlation between PC and line number
• By default, floating point exceptions are "imprecise" in that several more instructions may have executed before the error is reported. Try using /fp:except to see if the behavior changes.

I was running without optimization. Setting /fp:except (and adjusting to /fp:strict and turning off floating-point speculation as required by the /fp:except setting) certainly did change the behavour: the program now crashes while processing section 3829 during the first loop -- another fp overflow. The location is now unknown as the stack trace terminated abnormally.

Is there any way to cure this?

[Steven_L_Intel1]

Sounds as if you may have corrupted the stack somewhere. Without a test case, I don't know how I can advise you further.

Have you tried running this under the debugger?

[Dogbite]

Quoting - Steve Lionel (Intel)

Sounds as if you may have corrupted the stack somewhere. Without a test case, I don't know how I can advise you further.

Have you tried running this under the debugger?

Well, since you suggested it, I have. This is my first time w/ this debugger, and I found that the program was ending in an output routine. Mind you, this is about 115,000 sections before is should be doing any output! I note that when I hover over the input arguments they don't have values, instead the ominous notation "undefined address." This seems to suggest that the program is not entering the routine through the front door -- in fact the icon in the left column is a green arrow with the advisory that this is the next statement to be executed after returning from a call to some other function. Meanwhile the output window is showing a fp overflow at an unknown address. (sigh)

[Les_Neilson]

Quoting - Dogbite

Well, since you suggested it, I have. This is my first time w/ this debugger, and I found that the program was ending in an output routine. Mind you, this is about 115,000 sections before is should be doing any output! I note that when I hover over the input arguments they don't have values, instead the ominous notation "undefined address." This seems to suggest that the program is not entering the routine through the front door -- in fact the icon in the left column is a green arrow with the advisory that this is the next statement to be executed after returning from a call to some other function. Meanwhile the output window is showing a fp overflow at an unknown address. (sigh)

"Heisenbugs" (ones that move the closer you look at them) are often problematic to solve.
That said the usual cause is something overwriting memory it shouldn't (array bounds exceeded), mismatchedarguments (causing stack corruption) andthe process is

"implicit none" in all your fortran code
compile allDEBUG configurations with optimisation off, check routine interfaces on,
run time diagnostics array/string bounds and uninitialised variables on.

These should help narrow down the cause of the problem.

HTH
Les

[Dogbite]

Quoting - Les Neilson

"Heisenbugs" (ones that move the closer you look at them) are often problematic to solve.
That said the usual cause is something overwriting memory it shouldn't (array bounds exceeded), mismatchedarguments (causing stack corruption) andthe process is

"implicit none" in all your fortran code
compile allDEBUG configurations with optimisation off, check routine interfaces on,
run time diagnostics array/string bounds and uninitialised variables on.

These should help narrow down the cause of the problem.

HTH
Les

Now there's a term new to me: Heisenbugs. I've had a few of those in my time, and very tasty they are coated with ground nuts and fried. I love it.

Thanks, Les. I think I've got all those settings, but I'll check again. Mis-matched arguments can cause stack corruption? Didn't know that.

[jimdempseyatthecove]

Quoting - Dogbite

Now there's a term new to me: Heisenbugs. I've had a few of those in my time, and very tasty they are coated with ground nuts and fried. I love it.

Thanks, Les. I think I've got all those settings, but I'll check again. Mis-matched arguments can cause stack corruption? Didn't know that.

The return address from a call is stored on the stack. Should the argument mismatch cause you to overwrite the return address then it is off to La La Land. Also, calling a 3rd party library function or non-Fortran function with incorrect calling/returning setting will cause problems like this.

Jim Dempsey