When a run-time error occurs the debugger is not stopping on a Fortran code line

[Nathan_K_]

When there is a run time error while I am debugging my application via Visual Studio 2013, I expect that the debugger should stop on the line that is causing the problem. However, the debugger unexpectedly stops on a C++ code line in another part of our application.

The details of what is occuring:

1. a traceback dialog box titled "Intel(r) Visual Fortran run-time error" appears. It has correct traceback source code and line information about where the error happens in the Fortran code. The dialog has a single "OK" button.
2. I click "OK"
3. Visual Studio produces a dialog box indicating that my application has triggered a breakpoint. It has two buttons, "Break" and "Continue"
4. I click "Break"
5. The debugger breaks in our C++ code in another thread.
6. I navigate the through all of the threads in the thread window and observe the call stack window for each thread to try and locate the Fortran thread, but it is already terminated

What should should I do to signal the debugger to stop on the Fortran source code line instead of producing the run-time error dialog box with the traceback information? 

In VS2005 the behavior was for the debugger to stop in the Fortran source code and then when trying to continue the traceback information dialog box would be produced.
  
Our application is a C++ executable that calls Fortran dlls.

The Fortran compiler switches are as follows:

/nologo /debug:full /MP /Od /free /warn:interfaces /iface:cvf /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc120.pdb" /traceback /check:all /libs:dll /threads /dbglibs /c

The linker switches are as follows:

/OUT:"Debug\acerate.dll" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"acerate.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"acerate.pdb" /SUBSYSTEM:WINDOWS /IMPLIB:"acerate.lib" /DLL HTRILogging.lib

My system info:

Microsoft Visual Studio Premium 2013
Version 12.0.30110.00 Update 1
Microsoft .NET Framework
Version 4.5.50938

Installed Version: Premium

Intel(R) Visual Fortran Composer XE 2013 SP1 Update 2 Integration for Microsoft Visual Studio* 2013, 14.0.0086.12

[Nathan_K_]

I understand that it may be a while before I hear back on this issue. I do appreciate the feedback though; I'm expected to report on this issue tomorrow because it is one the issues preventing us from migrating forward.

I will try to eliminate variables to see if I can narrow down further where the problem occurs. I will report on what I find so I am not forgotten.

The reproducer project is the simplest version of how our software works: a c++ executable that dynamically loads and runs Fortran code in a new thread. I think the reproducer demonstrates there is in fact a problem and that I am not insane. Unless someone else cannot reproduce the problem.

I have had similar experiences dealing with incorrect dlls being loaded for a debugging session, so I have learned to verify that the correct libraries are loaded. Fortunately Visual Studio writes which dlls are loaded into the Output Window so it is easy to verify. In this reproducer case I see the correct dll and its symbols being loaded and I can debug through the c++ application and into the Fortran code okay.

In an effort to simplify the problem, I have tried debugging a single-threaded application instead of a multi-threaded one: a c++ executable, dynamically loading the Fortran dll, and running the Fortran single-threaded. In this scenario I found that I intermittently had the issue - sometimes I could see the Fortran call stack to the offending code correctly and sometimes I could not. It seemed that the debugger could get into a state where it would not produce the Fortran call stack to the offending code generating the runtime error. The debugger would stay in the state of not being able to show the Fortran call stack until I restarted Visual Studio and started a new debugging session. While I felt that debugging the run time error was flaky in this scenario, I was not able to figure out how to reliably reproduce the problem in a single-threaded mixed language application that dynamically loads a Fortran dll with a run time error.

[Steven_L_Intel1]

Ok, I just tried your example solution. All I did was a rebuild and then start in the debugger. I got the array bounds error, and the dialog to do a break. I select Break, I am put into the Fortran code with the call stack in place. The Locals window has the correct variables. I don't see any problem. See screenshot attached.

[Nathan_K_]

That screenshot is exactly what I am expecting to see! Thank you very much for taking the time to try to reproduce the problem I am having.

I have attached a screenshot movie of what happens for me. It's probably something specific to my environment, but I'm not sure how to troubleshoot the issue. I will try to reproduce this problem on other development environments/machines. 

[Nathan_K_]

I think that we have narrowed down the reason for this issue -- there appears to be an interaction problem that occurs when certain symbols are loaded. I have attached a screen capture movie that demonstrates reproducing the problem using the reproducer solution/project attached to Quote #16.

Essentially, when I choose to load Microsoft Symbols for a debug session, then it appears I lose the ability of the debugger to halt in the offending code on a Fortran runtime error. I was able to reproduce this problem in both VS2013 and VS2012 with Intel Visual Fortran Composer XE 2013 SP1 Update 2 Integration for Microsoft Visual Studio* 2013, 14.0.0086.12.

So... if you happen to run into this problem, empty the symbol cache and load only specified symbols to track down run time errors in the Fortran code.

I'd be interested to learn if anyone else can reproduce or observes this problem (because I've invested a significant amount of time in it) and also if it is an issue that will be resolved. I do not often need to load Microsoft Symbols, but I'd like to have the option without compromising other debugging features!