run time error with Visual Fortran Compiler XE 13.0

[jvandeven]

I recently tried to up-date to the new Visual fortran compiler (13.0.0.089), and have subsequently encountered a run-time error with my release configuration.  My application compiles and runs using my debug configurations, and compiles in my release configuration, but displays a run-time error when I run the release configuration.  My release configuration makes use of OpenMP dynamic link libraries (I know the most recent compiler release no longer allows for the statically linked library).  Furthermore, my release configuration appears to run just fine after compiling using compiler 13.0 (produces identical results to those obtained after compiling using previous version of the compiler), so long as I "check for null pointers and allocatable array references" (/check:pointer).  I believe that including this option is likely to lead to some loss in efficiency, and so would prefer not to have to resort to this work-around.

I include, below, my compiler options for your information.

Any help would be gratefully appreciated,

Justin.

FORTRAN:

/nologo /O3 /Qparallel /Qopt-prefetch=3 /Qip /Qopt-matmul /arch:SSE3 /Qopenmp /fpscomp:logicals /Qopenmp-report0 /Qpar-report0 /Qvec-report0 /real_size:64 /align:rec8byte /align:dcommons /fp:strict /fp:except /module:"x64\test" /object:"x64\test\\" /Fd"x64\test\vc100.pdb" /gen-dep:"x64\test\SIDD.dep" /libs:static /threads /Qmkl:parallel /c /F900000000 [only works if I add the option /check:pointer]

LINKER:

/OUT:"C:\MyFiles\MODEL_LAB\MODEL\SIDD.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\MyFiles\MODEL_LAB\MODEL\\" /MANIFEST /MANIFESTFILE:"C:\MyFiles\MODEL_LAB\MODEL\SIDD.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /MAP:"x64\test/NIBAX.map" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /IMPLIB:"C:\MyFiles\MODEL_LAB\MODEL\SIDD.lib" taxes.lib excel.lib analysis.lib

[jvandeven]

This issue continues to detrimentally affect the performance of my application, relative to compiler 12.1.2. I have tried tracking down the run-time error, but have struggled as the error only appears in my release configuration that omits all run-time checks, so that the program window closes before I have time to register the error message. Is there some way to identify the run-time error message other than through the program window (which closes before I can read the message that I think is displayed)? At present this problem is preventing me from updating to the new compiler.

[IanH]

Your program is a console program? If so, is there anything stopping you from running the program from a console (command prompt) session?

[Steven_L_Intel1]

And what is the run-time error? You didn't say. Please show the complete and exact text.

[jvandeven]

It is a consol program, and I didn't realise that running it from the command prompt would allow me to see the run-time error messages - I have always had to resort to my debug configuration to read these messages in the past, as the command window in the release version closes too abruptly otherwise; thanks for the useful tip. The error message reads "forrtl: severe (157): Program Exception - access violation" - I attach a screen shot to provide further detail. Unfortunately, this run-time error message doesn't help me to understand what is going run, but I do notice that the OpenMP dll appears to be involved (see the screen shot). Any help you could give me would be much appreciated. Justin

[IanH]

Turn on the /traceback option for the release build (in the properties for the project in Visual Studio under Fortran > Run-time set Generate Traceback Information to Yes.) and run it again. (You've got 900MB of stack specified in your options in your original post. Is there a possibility that's not sufficient?) (For future screen shots try Alt-Print Screen to copy the image of the current window only to the clipboard (as opposed to an image of your entire desktop).)

[jvandeven]

I turned on the /traceback option, and received the message "Traceback functionality does not work when the Omit Frame Pointers optimization is set to Yes in the Fortran Optimization category or when Enable Incremental Linking is set to Default or Yes in the Linker General category" regarding the first of these, the "Omit Frame Pointers" optimization appears to have been replaced with something else, and I am not sure whether I have this "something else" turned on (the Linker General category is turned off). Nevertheless, the program now produces more detail regarding the error - see attached screenshot and code snippet. The error appears to be occurring at the beginning of a loop (see code snippet). Both variables ii and nexp_here0 are defined as type integer(4), and nexp_here0 is set equal to 1 (top of the code). This suggests to me that it is a threading problem, which makes me worried, as the subroutine that is being called here is a subroutine within the paralelised region, that shares only a small subset of global variables with other subroutines, none of which are varied within the paralelised region (ii and nexp_here0 are local variables within the given subroutine). This problem only appears in the most recent version of the compiler, and then only when I suppress the /check:pointer option (which also seems strange)... Many thanks for your help, Justin.

[IanH]

Humour me - make the stack reservation bigger. Stack usage is something that a change in compiler version could change. Do all of your source files have the same compile settings? With the optimisation settings that you have the line location in the traceback is probably nominal. The references to those Op_exp0 arrays (or any variable, really, in the body of that do loop) would be things that I'd look at and try and consider if they could be problematic. Ways of trying to pin down the location further (write statements etc) might be worth trying, though the resulting code changes from inserting that sort of stuff can often obscure/obliterate the underlying problem. What happens if you wind the optimisation level back a notch? The presence of /check:pointer could change how the optimiser arranges the code. What happens if you are running a serial release build (/Qopenmp_stubs) or a no omp build? After the above poking around I'd start looking at the disassembly to try and map the specific memory reference that caused the violation back to variables in my Fortran program, progressively reducing optimisation settings and increasing debug settings along the way to try and make that task easier. (Sometimes those progressive changes can influence whether the access violation occurs or not before I work out what's going on, in which case I sit on the floor and throw a tantrum.)

[jvandeven]

The reason that I haven't fiddled with the stack reservation is that this problem occurs whether I consider problems with small or large memory requirements. In any event, I re-compiled using 9GB (extra 0), with no improvement. Interrestingly, the problem remains unchanged (same error code, same trace) when I implement /Qopenmp_stubs, and a no omp build - so thankfully, it is not the OpenMP dlls at fault. This gives me a good place to work from - I will send a post if I find what is going wrong. Many thanks for your very helpful pointers, Justin.

[jvandeven]

I have started to try and track down the error referred to here, but my efforts are significantly hampered by the fact that I cannot check variable values through the watch window when higher level optimisations are implemented. As the error that I am encountering only appears when optimisations are implemented, I am a bit stuck. I would appreciate any advice on how to adjust my compiler options so that I can see variable values through VS 2010 in debug mode. The compiler options that I currently have are listed here: FORTRAN: /nologo /debug:full /O2 /Qparallel /Qopt-prefetch=3 /Qip /Qopt-matmul /arch:SSE3 /fpscomp:logicals /Qopenmp-report0 /Qpar-report0 /Qvec-report0 /debug-parameters:all /real_size:64 /align:rec8byte /align:dcommons /fp:strict /fp:except /module:"x64\debug_complete" /object:"x64\debug_complete\\" /Fd"x64\debug_complete\vc100.pdb" /gen-dep:"x64\debug_complete\SIDD.dep" /traceback /libs:static /threads /dbglibs /Qmkl:parallel /c /F900000000 LINKER: /OUT:"C:\MyFiles\MODEL_LAB\MODEL\SIDD.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\MyFiles\MODEL_LAB\MODEL\\" /MANIFEST /MANIFESTFILE:"C:\MyFiles\MODEL_LAB\MODEL\SIDD.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"x64\debug_complete\SIDD.pdb" /MAP:"x64\debug_complete/NIBAX.map" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /IMPLIB:"C:\MyFiles\MODEL_LAB\MODEL\SIDD.lib" libiomp5md.lib taxes.lib excel.lib analysis.lib RESOURCES: /l 0x0809 /fo "x64\debug_complete/SIDD.res" Many thanks, Justin.

[lklawrie]

You could try using all your release compiler options (optimization, etc) but with debug full in the debug mode. That might let you track it.

[jvandeven · Accepted solution]

I selected /debug:full, and have been running the program through the debugger, but variable values are always out of scope. I have resorted to using print statements, as suggested above by IanH, which didn't help too much. It turns out that the commands that the program selects for execution in the part of the code where the error occurs, is quite strange - I provide a code snippet here: 1 do ii = 1, nexp_here0 2 if ( (cp2_state.eq.3).or.( ((cp2_state.eq.2).or.(cp2_state.eq.4)).and.(pen_receive.eq.1) ) ) then ! cp2 modelled on OP axis 3 OP_exp0(ii) = OP_exp0(ii) + cp2_cont * cp2_xdr(age_index,spa_regime) 4 end if 5 if ( OP_exp0(ii).gt.max_op ) then ! additional pension contributions not possible, as have already reached pension limit 6 OP_exp0(ii) = max_op 7 else ! can take in additional pension contributions 8 OP_exp0(ii) = OP_exp0(ii) + OP_contbn 9 if ( pen_receive.eq.1 ) then ! PP modelled on OP axis 10 OP_exp0(ii) = OP_exp0(ii) + PP_contbn 11 end if 12 end if 13 end do In this code, nexp_here0 = 1 and cp2_state = 0. The error is being identified at line 3. The code jumps from line 1 to 2 and then 3 when the optimisations are turned on, and performs what I can only assume is some sort of pre-processing. Most of the time this pre-processng works just fine, but in this case it throws up the error I have referred to. Given the above, I have moved lines 2-4 outside of the do loop (as this is where the error occurs), and the code now runs through without a hitch. An unsatisfying work-around, but at least it works! Justin.