Source Not Available while debugging

[LucaD]

Hi all,

This is my first post here so, let me introduce myself. I am a research scientist and for most of my work I have to deal with a simulation model written in Fortran. I don't have any official training on Fortran and programming and, all I know comes from reading, working with colleagues better programming skills, and a lot of experimenting and playing.

After many attempts, I am not able to solve the problem I am facing now. I am working on Windows 10 and I use Visual Studio Professional 2017 plus Intel Parallel Studio XE 2019 Composer Edition for Fortran to work with the source code of the simulation model I use. Sometimes it happens that the debugging process stops because of a problem, but the executions stops with the message "Source Not Available" and the only option available is the "view disassembly" which brings to a new window that, honestly, I can't understand.

What is strange is that if I debug the same source code using the same input data using Visual Studio 2008 plus Intel Visual Fortran Composer XE 2011, the debug process stops at the line of code where the problem occurs and so, I can understand what the problem is.

I don't know if the problem is created by the Fortran compiler, by Visual Studio, or if it is created by some setting that I have to take care of.

Is anyone able to provide some advice on how to solve this issue? Attached are two images, one shows the situation when I get the message "Source Not Available", while the other shows what I consider the normal/expected result of the debug process. Let me know if I need to provide more information.

Thanks,

Luca

[mecej4]

I suspect that the program contains errors of such a nature that the behavior is "undefined". If, for instance, a variable is used without having been assigned a value earlier, what you observed can occur. In fact, the same EXE when run at different times can display different behavior.

Only one of your screenshots shows a stack trace. If, in the other run, you look at the stack trace when the program stops, you may see that the program has stopped at a differnt location. 

Such errors can be difficult to debug, and not much can be said without having the source, include and data files available.

[jimdempseyatthecove]

When this type of error symptom appears (Source not available) it is often caused by passing in a reference of an undefined variable to a runtime library that was built without debug information. The way to obtain some insight to the problem is to examine the Call Stack window (unfortunately obscured in your SourceNotAvailabl.PNG) and then double click on a higher call level. This may be up one, two or more levels until you reach a level in your code with debug information.

Jim Dempsey

[LucaD]

Thank you all for the suggestion.

As soon as possible, I will run again the program with the same input files and I will look at the Call Stack window (if I remember correctly it shows only one line, but I might be wrong). I will post a new screenshot to show the call stack when the program stops.

Out of curiosity, does any of you know why the two version of the compiler and Visual Studio produce different results when using exactly the same source code and input data?

Thanks,

Luca

[mecej4]

There are many types of errors in programs that can cause a them to give different results at different times in an unpredictable way. It is not necessary to change compilers to see such errors.

Here is one simple example. Compile the program once, and run the resulting EXE a few times.

program undef
integer :: i,j
j = i
do i = 1,5
   j = j*i
   print *,i,j
end do
end program undef

Examine the outputs from different runs. Do they look "right"?

Examine the program. It is short enough to simulate on paper. What should the program output?

Earlier, you wrote: "... the debug process stops at the line of code where the problem occurs and so, I can understand what the problem is." Those are the easy problems. There are many instances where there are many lines of code, if not whole subprograms, that are executed between the point at which a bug was initiated and the point at which an observable symptom exists.

In fact, I feel that "debugger" is most often a misnomer for what is, at best, a diagnostic tool. 

[LucaD]

Dear all,

As promised in my last message, I run the program again and took a screenshot, this time shoving the Call Stack window. As you can see, I have only a line, and it is not very informative for me. Also, you can notice that also the command prompt window doesn't show any information on the error compared to what is visible in the image I named StopAtLineOfCode.

@mecej4 thank you for the additional information and the little example/exercise. I compiled the program using the same setting I used to compile the code of the simulation model I am working with. I executed several times (from Visual Studio and from the command prompt) and it never failed, producing values for "i" from 1 to 5, while "j" remained at 0 for all the five iterations.

So, I think that, if there is not a way to let the most recent Visual Studio and Fortran Compiler to point me in the general direction of the error, my best solution is to keep an old version of Visual Studio and Fortran Compiler for when I run in this problem again.

Also, I think I have never mentioned that the error in the program was that the first subscript of one variable, during the simulation, reached a value greater than its upper bound (as you can see in the image StopAtLineOfCode).

Again, I don't know if there is a solution to this problem and I really appreciate your help.

Thanks,

Luca

[mecej4]

Here is the lesson from the little test program.

The variable i is undefined when it is first used, and j is set equal to that undefined variable. From that point on, the behavior of the program is "undefined". The values printed out for j are meaningless, and that you saw 0 printed out does not establish that the correct value is 0.

Reproducibility does not necessarily imply correctness.

[jimdempseyatthecove]

tbk_get_pc_info_pie is a part of the Intel Fortran error traceback diagnostic. For this to fail, something is quite wrong with how you linked and/or your program run (up to point of failure) corrupted the program to the point where the Fortran error traceback diagnostic errored in generating the traceback information. An example of this might be in corrupting the stack pointer register.

I suggest starting your program in Debugger with break at first statement, then stepping through the program (either line-by-line or in manageable groups of lines).

Note, if the program fails before breaking at first line, then on Windows/MS VS use:

    Debug | Step Into

as opposed to Start Debugging

Then you will need to step through the startup code (which generally is in assembly.

If the error is in the startup code, and you are unable to work with the assembly code, the recommended path is to remove/comment out source lines that perform pre-PROGRAM/main initialization such that you can reach the 1st break point at the start of PROGRAM. Then add back those source lines until the error occurs and that at which point, figure out what you did wrong.

Jim Dempsey

[LucaD]

Dear Jim,

What you wrote in your last comment ("something is quite wrong with how you linked and/or your program run") make me wonder if there is something I need to change in the setting of the linker and if this is why the old version of the compiler is not showing the problem. I will explore this possibility.

I will follow your advice but, it can take me some time since the program has about 20,000 lines. I am sure the program will not break before the first line because I did this test before. So, I think I will not need to go through the steps you described, but I learned something new.

Also, I am about to update my system with VS2019 and a new version of the Intel Fortran compiler. Hopefully, this combination will solve the problem.

I will let you know how it goes. Thank you all for the suggestions and support!

Best,

Luca