Debugger - Viewing main subroutine locals used in a contained subroutine

[davidspurr]

I know how to view module variables in the debugger, but have not found out how to view variables local to a subroutine from within a contained (internal) subroutine.

Surely it is possible? Alas I can not find reference to it in the User Guide.

David

[sabalan]

In CVF (or VS 6.0) you normally see "Context" bar at the top of the little "Variables window" when debugging. Click on the little triangle to the right side of the context bar, browse and select the higher subroutine in the list. You are going to jump into that subroutine and a green arrow is going to show where in that subroutine you are. Now you can see and examine all variables in that subroutine.

I think there must be something like this in IVF (VS .NET) too.

Sabalan.

[davidspurr]

Thanks Sabalan

Unfortunately I cannot find this in the watch or quickwatch windows in IFV 8. You say "Variables window". I do recall it from CVF/VS6, but cannot locate it in IVF8/VS.NET?

For a breakpoint in an internal routine, the "Locals" window only displays variables that are strictly local to the internal routine & I see no context bar or similar means to access local variables from the parent subroutine. Same with the "Watch" & "QuickWatch" windows - no apparent access to local variables from the parent subroutine. Adding them to a watch window results in "Undefined variable xxx" being displayed. The same problem occurs viewing variables defined in a module & referenced via a USE statement in the parent routine.

There also seems to be a problem with derived type allocatable arraysdeclared in amodule if the arrayis ALLOCATED and values computedin an internal routine. Both in the internal routine & onreturn to theparent subroutine in which the USE statement appears, the watch windows just shows nonsense values for the "array" components.In fact, each component had the same nonsense value for every member of the array; eg. "Seismicity_model::EQ(i)%magnitude"displayed the same nonsense value for all valeus of "i"; "Seismicity_model::EQ(i)%xcoord" displayed a different nonsense value, which was the same for all values of "i"). They definitely are not nonsense values- confirmed by looking at the values of local variables that obtained their values from the array components.

A bit of an obstacle to debugging.

Any workaround possible (other than adding a new local variable & equating it to the external one I want to view) ? Or am I completely missing something?

I found nothing on these issues under "Viewing Fortran Data Types in the Debugger" in the User Guide.

The debugging facilities need a major shakeup. The watch windows should provide access to variables in the same manner as in the program code; ie. specify any variable used in a routine by the same name that it is called in the program. If the program knows the value of the variable without having to precede it by the name of the module etc, then why can't the watch windows act similarly.

Ideally, the watch windows would display the name of the module or subroutine the variable is defined in. eg add another field for "Location" (or "Defined in") to the watch window.

Having to specify the module name for each variable is a right pain (& the lack of access to "external" variables used in internal routines, an even bigger pain). Seems I made a mistake using these new fangled f90/95 features (internal routines & modules). Unfortunately I used (long) descriptive names for modules, since the module name length does not impact on the code - just called up once at the start of each subroutine. Alas, not so convenient having to specify the module name in front of every variable name in the debugger!

David

[sabalan]

David, can this NEWtopic help you?

Sabalan.

[a_leonard]

The link in Sabalan's post doesn't get me anywhere. Can you post the new topic subject so that I can search for it?

[Steven_L_Intel1]

That link isn't valid anymore. I am not sure what post that Sabalan referred to.

I believe it is the case at this time that the debugger can't see host-associated variables. This is being worked on.