Data breakpoint question

[dondilworth]

How do I set a breakpoint that will trigger when a given Fortran variable gets changed somewhere? There seems to be such a feature in VS10, but it ignores my Fortran variables -- which get changed with no break triggered.

[jimdempseyatthecove]

Try this (in VS in edit mode, Debug build):

Debug | Delete All Breakpoints (*** do not omit this step ***)
Set breakpoint at first statement in program
Run (to breakpoint)
Find a variable that is in the scope of the main thread (including global variables) that will shortly be modified. Click mouse pointer on variable, then

Debug | New Breakpoint | New Data Breakpoint

Place second statement breakpoint on a line after statement that modifies variable, then Continue

See if data breakpoint breaks before at line breakpoint breaks.

This test confirms if databreakpoints work or if you are using it with false assumptions.

Some things to remember:

1) OpenMP private variables are difficult to set data breakpoints (ambiguity as to thread scope context)
2) Data breakpoints resolve (at runtime) symbol/expressionto address and save the address (IOW text of symbol name/expression not saved)
3) Because address (2) is saved for data breakpoints theData breakpoints are not preserved as activeacross runs. If you edit source or break within an allocated object the addresses may vary from run to run.

Jim Dempsey

[WSinc]

I had a problem when trying to set a complex breakpoint condition, and Steve recommended using the DebugBreak call, which always sets it.

The problem with that though, is you can't disable it whenever needed.

What we really need is a way to enable/disable breakpoints at execution time, i.e. from the source code.

In other words to intereact with the breakpoints from within the executing code, if that's possible.

Another helpful feature would be to completely disable any optimization when trying to DEBUG a program,
that would remove a lot of the confusion. The one could re-enable the optimization for production runs - -
hopefully the behavior would then be unchanged.

[jimdempseyatthecove]

>>The problem with that though, is you can't disable it whenever needed.

Change:

call DebugBreak

subroutine foo()
implicit none
logical, save :: Break1 = .true.
...
if(Break1) call DebugBreak()


Then set or unset Break1

>>Another helpful feature would be to completely disable any optimization when trying to DEBUG a program, that would remove a lot of the confusion

This is why you select (in Visual Studio) the Debug Build

The second line of the toolbar (usually) has two drop-down boxes. The left one (usually) contains

Debug
Release
(your other build configurations here and below)

The right drop-dow s (usually) platform

Win32 (32-bit Windows)
x64 (64-bit Windows)
(your other platforms here)

Jim Dempsey