erroneous trace back listing in release mode

[LRaim]

I have experienced many times a wrong trace back listing in case of run time errors.

The following is a case:

      Output/plot unit   7 PL1      - time    4:00:00      P.  49
forrtl: error (73): floating divide by zero
Image              PC        Routine            Line        Source            
XDSIMV10.EXE       00F32D62  _HB256                    272  V1CORR56.FOR
XDSIMV10.EXE       010783B1  _DY56_FLOW               1071  V0DUOP56.FOR
XDSIMV10.EXE       01077EF5  _DY56_FLOW               1135  V0DUOP56.FOR
XDSIMV10.EXE       0107273C  _DYUO56                   263  V0DUOP56.FOR
XDSIMV10.EXE       00F8DC06  _DY02_PROP                156  v0prop02.for
XDSIMV10.EXE       00F880CC  _DY02_PROP                193  v0prop02.for
XDSIMV10.EXE       0101CD2D  _DYNAMIC_SOLUTION        1044  V0DYNSOL.FOR
XDSIMV10.EXE       01130866  _MAIN__                   525  V0XDSIM.FOR
XDSIMV10.EXE       013FACA2  Unknown               Unknown  Unknown
XDSIMV10.EXE       011D6172  Unknown               Unknown  Unknown
kernel32.dll       7649EE6C  Unknown               Unknown  Unknown
ntdll.dll          76E03AB3  Unknown               Unknown  Unknown
ntdll.dll          76E03A86  Unknown               Unknown  Unknown

The subroutine DYUO56 is not called by DY02_PROP and the double listing of DY02_PROP is also wrong.

The routine called at line 1044 of V0DYNSOL.for is not DY02_PROP. The initial lines of the trace-back are correct so the error point can be identified. However these imperfections do not place  the user at easy.

COMPILER: Intel(R) Visual Fortran 15.0-1750
 

[Steven_L_Intel1]

Without seeing a test case, I would guess that there is procedure inlining happening, which will cause traceback to be perhaps more confusing. Are you able to provide us a test case we can build and run to check it out?

[LRaim]

Steve,

it will take too much effort and time to prepare a test case from thousands of lines of codes.

The DY02_PROP routine was involved in a previous calling sequence.

What I can provide is an Excel form showing the two calling sequences; i.e. the one generating the error (xyz56_... path) and the previous one (xyz02_... path).  

[mecej4]

Luigi R. wrote:

it will take too much effort and time to prepare a test case from thousands of lines of codes.

Yes, but that is necessary in order to move forward towards a solution. First, we have to establish that there exists a bug. It is only after doing so that we can look for a solution.

Suppose you have a program with a few thousand lines of code, which reads some data and produces results. You provide the EXE to a colleague, who runs the program and uses the output. Most of the time, the colleague finds the results "fine". For some inputs, however, she finds the results "suspect". Would you undertake to debug your program without being given at least one set of input data for which the results are suspect?

Now instantiate the program with a suspected bug as the compiler (behind it may be millions, rather than thousands, of lines of code). Luigi's programs are the input data to the compiler. The compiler is the EXE of the preceding paragraph, and Luigi is the "colleague". Most of the time, the compiler produces fast, correct output (working EXEs). The colleague (Luigi now) has found one input data set (thousands of lines of source code that may have caused the compiler bug to occur). Unless he provides the data (the source code of his malfunctioning program) to the compiler developer team, what can they do to solve the problem?

[TimP]

Following Steve's suggestion, you could try suppressing inlining or setting debug:inline-debug-info to attempt a more accurate traceback.

[LRaim]

To complete the discussion about this subject.

The trace back seems to loose the calling sequence and mix the last sequence which generates the error with the previous one. The two sequences are as follows:  

Main is : PROGRAM XDYNSIM  but the name is lost.
Call sequence 1 (completed with no errors) :
_MAIN__                   at line 525  of V0XDSIM.FOR calls
_DYNAMIC_SOLUTION        at line 1044  of V0DYNSOL.FOR calls
_UOPXX               at line  796  of v0uopxx.for calls
_DYUO02              at line  413 of  v0duop02.for  calls
dy02_prop                             v0prop02.for

Call sequence 2 :
_MAIN__                  at line 525  of V0XDSIM.FOR  calls
_DYNAMIC_SOLUTION     at line 1044  of V0DYNSOL.FOR  calls
_LNK_UOP                 at line   411 of V0lnksol.for  calls
_LNK_SOL                at line   978 of V0LNKSOL.for  calls
_uopxx                      at line   362  of  v0uopxx.for  calls
DYUO56                  at line  263  of   v0duop56.for   calls
dy56_flow                at line  1468 of   v0duop56.for  calls
dy56_fric                  line 1468  of  v0duop56.for  calls
_HB256                               in module V1CORR56.FOR

The subroutine DY56_FRIC is inlined in the release version. 

Compiler developers should give a look into this.

Regards

[Steven_L_Intel1]

Sorry, without a test case there's nothing to look at.