Debugging internal Fortran subroutine

[Philippe_B_]

Hello,

I have a Fortran subroutine that has internal subroutines and functions which it calls. The program runs, but once I step into an internal subroutine, debugging variables define in principal usbroutine is impossible. It is as if it does not inherit the debug information from the enclosing subroutine. All the variables are undefined in the debugger.

Does anyone know how to get around this problem ?

Visual studio version : 2012 update 4

Intel® Parallel Studio XE 2015 Update 4 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2012, Version 15.0.0122.11

Regards

Philippe Boyat

[Steven_L_Intel1]

You can use the "Stack frame" dropdown to set the context to the caller and see variables defined there.

[Philippe_B_]

I have seen this answer from you in an old  post (2007) but also this : 

"It is an issue we are working on and expect to have it fixed in an update to version 10.0"

So i have supposed that it was fixed in Intel® Parallel Studio XE 2015 Update 4 but it seems not.

I have tried but even in the call stack, i don't have access to variable defined in principal routine and use in internal function : 

>    PYL-V40-EN13001-64bits.exe!PYSTA_NEW_EN13001_ip_PROCESS_MT_CHARGE(REAL(4)  COEF_2ND_ORDRE=1.411864 , REAL(4)  PHI_EN13001=1.100000 , REAL(4)  EQUARISSAGE=10.00000 ) Line 412    Unknown

In the code above, i don't have access to some variables and they are replaced by REAL(4). These variables have been defined in the principal subroutine.

Others variables that are accessible are variables defined or enter as arguments in the internal function "PROCESS_MT_CHARGE"

[Steven_L_Intel1]

Perhaps you have a different problem. Can you provide a small but complete example that demonstrates it? I just tried an example and the stack frame pulldown worked.

[Philippe_B_]

To be more clear i have made a little example : 

program Test_internal_sub                                
implicit none                
                             
REAL :: var1                 
REAL :: sum_result                     
var1 = 10.0                  
                             
sum_result = Summation(2.0)  
print*,sum_result            
                             
CONTAINS                     
  FUNCTION Summation(var2)   
    REAL :: Summation        
    REAL :: var2             
    Summation = var1 + var2  
  END FUNCTION               
end program Test_internal_sub

When i am in function summation, i have no access to var1 value.

Do you want i send the project or this code is sufficient ?

[Steven_L_Intel1]

Works for me... You can also just hover the mouse over the host variables and their values will be displayed, even without the stack frame adjustment. Or you can add a QuickWatch. The "Locals" pane shows only the locals of the current scope.

[DavidWhite]

Steve,

I too am seeing strange things when debugging, especially within CONTAINed subroutines.

On occasions, VS has shown me the wrong type for a variable (INTEGER instead of REAL(8)), and as in the example below, saying the variable is undefined within the CONTAINED subroutine, but present when the routine is exited.  Hover over the variable produces no results, either.

Regards,

David

[Philippe_B_]

Thanks for your reply.

I have tested and it works. I need also to add debug location toolbar in order to be able to use stack frame dropdown button.

By the way, i see that when you continue to debug, you lost the stack context you have chosen. Is there a way to keep it ?

Regards

[Steven_L_Intel1]

You mean that when you continue execution, the stack frame resets to current? I don't know of a way to do that. As I mentioned, hovering over the name seems to do what you want.

[Philippe_B_]

Yes but hovering over the names works only if the correct stack frame is chosen. If not hovering over names produces no result.

So each time i press F11 in the internal subroutine, the stack frame reset, so i need to rechoose the right one to be able to see variables values.

[jimdempseyatthecove]

If you can figure out the hot-key key strokes, you can define a VS macro (and hot key) to perform the F11 and pop-stack frame reference.

Jim Dempsey

[Steven_L_Intel1]

My experience is that one doesn't need to change the stack frame to use hover.

[mecej4]

I am only an occasional user of the VS debugger, and I am bit mystified by the points brought up in this thread.

Since a project can have only one active version of each source file in it, the hover point completely determines context without needing the user to select a stack frame, does it not? Or is there some version control system involved?

If my guess is correct, the failure of VS to display a value, after the user's hovering the mouse over a variable, would indicate that the mouse is in a text window of a source file that is not part of the code being debugged -- it could be a previous version, a copy of the source in a different directory, or it may be the case that the particular source file was compiled without debug information emitted, etc.

I am just trying to understand the reasons behind the symptoms that have been described.

[DavidWhite]

Every time I step through the contained routine, the Stack Frame is reset to current, which means that to check every variable, I need to set the Stack Frame on every line (Hover doesn't work until the Stack Frame has been reset to the caller).  Makes having contained routines a real pain to debug.

David

[Jonathan_H_]

I'm also having this problem. Debugger won't show the variables in the parent subroutine when my debugger is inside a CONTAINed subroutine.

I'm also getting variables listed twice in the locals watch window.

This is using Version 15.0.1.148 Build 20141023 in Visual Studio 2013.

[Steven_L_Intel1]

Jonathan, you should try a newer compiler.