How to find mysterious clobber?

[WSinc]

An array cell is getting wiped. I suspect it is a runaway subscript somewhere.

The debugger does not catch the runaway subscript.

Is there a way to turn it loose, and just monitor that cell to see which instruction is doing that and where?

Unfortunately, a watch window doesn't work, because I would have to step thru thousands of instructions by hand.

It would take weeks.

[ZlamalJakub]

Try Debug-New Breakpoint-New Data Breakpoint

To Address set for example Array(1000) if problem occurs at 1000th element of array

Byte count leave at 4

and press OK button.

This breakpoint occurs when Array(1000) value is changed

Jakub

[Steven_L_Intel1]

Jakub's method is the first to try, but it may make the program run much slower or noit catch the change. The next thing to try is to add a QuickWatch for the element in question. Set breakpoints in various places and watch for the value to change when it shouldn't. You will probably have to move breakpoints around as you narrow in on the change.

If the QuickWatch doesn't work, use the Debug > Windows > Memory window to watch the location of the array element (you may have to add a print of LOC of the element to get the address.)

[WSinc]

I don't understand -

For "language choice" I don't get Fortran, I get only C or C++

When I look at the address, it gives some nonsense value that isn't

anywhere close to the address I want to monitor.

Is this feature supposed to work at all?

Did anyone even bother to test it?

[WSinc]

OK, I will try that.......

In the Fortran VS debug, it doesn't seem to compute the actual HEX address of

the element correctly. Possibly because I'm using arrays with a

lower limit of 0, and specifying a location of (0,0) to watch.

C or C++ does not allow 0 or negative subscripts, so perhaps this

feature wasn't thoroughly tested for Fortran code (?)

One thing that complicates this: When I alter the code, it can change the HEX address of the element I'm looking at. Maybe putting the array in COMMON would prevent that?

Do COMMON blocks get loaded ahead of the executable code and local variables?

[Steven_L_Intel1]

Fortran is not a language choice for data breakpoints. Use C. You could just give the name of the array and 4 bytes to watch or, as I suggested, print the address of the array element you want to watch and then specify that in the data breakpoint.

COMMON blocks are part of static storage. There's no defined order, but they will certainly be loaded before local scalar variables.

[jimdempseyatthecove]

To convert a Fortran array element into an address open a Memory window and type in the Fortran address ARRAY(123). The name you type in will be replaced with the hex address. Use the mouse to select the address (click and hold to the left, drag to the right, then Ctrl-C). Next go to the Debug | Break Points dialog and click on Data break. For the address perform the paste (Ctrl-V). Leave the "language" at C/C++ and the size at 4 bytes. Now continue (F5). Every time the location changes you will get a break point at/inside/after the statement that altered the memory. You can have up to 4 memory change break points with no degredation in performance.

[WSinc]

First of all, thanks for your suggestions - - -

I realize that perhaps it is NOT the language choice, but I am stuck with a Fortran application.

Unfortunately, converting it to C++ would introduce a giant can of worms. It makes extensive use of

zero or negative subscripts, and lots of special I/O calls. So I have to keep it as a Fortran App.

It is a special multiple precision integer arithmetic package.

But if they DO have that feature in the VS debugger for Fortran, is it asking too much to have it work "as advertised?"

Maybe this is being too "political - - - " (?)

[Steven_L_Intel1]

If there's a problem with Fortran variable references in data breakpoints, we'll try to fix it. I'll do some experiments when I get back to the office to see. If you have a test case, that would be helpful. I will note, though, that the data breakpoint feature hasn't been too reliable, even for C, over the years.

[Jeffrey_A_Intel]

Quoting billsincl

First of all, thanks for your suggestions - - -

I realize that perhaps it is NOT the language choice, but I am stuck with a Fortran application.

Unfortunately, converting it to C++ would introduce a giant can of worms. It makes extensive use of

zero or negative subscripts, and lots of special I/O calls. So I have to keep it as a Fortran App.

It is a special multiple precision integer arithmetic package.

But if they DO have that feature in the VS debugger for Fortran, is it asking too much to have it work "as advertised?"

Maybe this is being too "political - - - " (?)

I don't think Steve is suggesting that you rewrite the application in C (or C++). What (I think) he's saying is that the Visual Studio debugger only gives you the choice of C or C++ syntax for the addresswhen creating a data breakpoint and that you should chose C.

The reason Fortran is not a choice is that this particular capability in Visual Studio is not extensible (just one of many but that's a different rant) and there's no way to add Fortran as a language choice. You have to talk to it in a language it understands and it doesn't understand Fortran. However, it does understand LOC. So, when giving the address of the bits to be watched by a data breakpoint, one can say things like

LOC(i)

LOC(a(50))

and

LOC(a(i))

And this gets tested with every release.

[jimdempseyatthecove]

>> However, it does understand LOC.

Are you saying:
Debug | Windows | Break Points | Break on data | Location: LOC(a(i))

This seems incongruous since the language is C/C++ and LOC(a(i)) won't evaluate.

However, when you use:

Debug | Windows |Memory | Location: LOC(a(i)) or just a(i), or a(123)
(or simply click on Memory tab if already available)

This works because Memory/Location is in language of application (Fortran)

Then upon accepting the Location, the location address displays the hex address (0x0000abcd...)

This address can be copied (highlight, Ctrl-C), then:

Debug | Windows | Break Points | Break on data | Location: Ctrl-V (paste)

This works

Jim Dempsey