Breakpoints on array elements

[jcl2]

At the risk of seeming foolish because I have missed some blindingly obvious setting, I am having problems setting breakpoints (IVF9.0/Studio.net 2003) when elements of an array change.

In the following program:

program memory
real, pointer :: f0(:)
integer i,ierr

i=3000000
allocate(f0(i),stat=ierr)
if(ierr.eq.0) then
f0=0.0
write(6,*) 'allocated f0(',i,') ',i
else
write(6,*) 'failed at 0'
endif
end

compiled with:
/nologo /Zi /Od /warn:all /warn:declarations /warn:unused /warn:ignore_loc /warn:truncated_source /warn:interfaces /Qfpstkchk /iface:mixed_str_len_arg /module:"$(INTDIR)/" /object:"$(INTDIR)/" /traceback /check:all /check:bounds /RTCu /check:format /check:output_conversion /check:arg_temp_created /libs:static /dbglibs /c

I set a breakpoint 'when f0(10) changes'. The attached screen shot shows that after the ALLOCATE the debugger can see the value of f0(10). I then press F5 to continue, and stop at the write(6 line, having sailed past f0=0.0.

In the screen shot, the breakpoints window shows a little ? next to the data breakpoint, and the properties for it say:

The breakpoint will not currently be hit. Unable to currently find data: f0(10)

which is presumably not true because the watch window shows f0(10) correctly.

When the same program is run with CVF6/DevStudio6, it stops at the f0=0.0 line as expected.

I have seen the same problem in my real code, and if this is a genuine problem it makes the IVF9/Studio.net 2003 combination of very little value to our company.

It is a life-saver to trace elements of an array - it worked so well in CVF6/Studio6 I cannot believe it does not work now so I must be doing something dumb.

Whilst on the subject of Studio.net:
# if I right-click on C code in the source browser, I can compile multiple files. If I right click on Fortran and select more than one file, the compile option is greyed out. Why? It wasn't in DevStudio6.
# is it possible to un-dock the source-editing windows and make them overlap - it is not always convenient to have them in a tabbed view.
# is it possible to place the 4 watch windows into a tabbed pane - it is not always convenient to have all of them taking up screen space.

[Steven_L_Intel1]

Please report this to Intel Premier Support.

[jim_dempsey]

I have experienced the same problem and have a work around.

This is a hack, but what you can do is open a memory window and enter in the expression that you want

f0(10)

Then you will notice that the expression you wrote turns into a hex address: e.g. 0x00112234

Copy this address into the paste buffer without the 0x: e.g. 00112234

Next open the Break Point window and then Add new breakpoint.

Click on the data tab and paste the hex address into the location edit box.

*** remember to add a lowercase h onto the address: e.g. 00112234h

Leave the number of elements at 1

Now, when this location is written to you will receive your break.

N.B.

When I examined this problem last year I noticed that when entering a symbolic address into thebreak on memory change thatthe Debugger was setting an Execution Breakpoint at the data address.

This was evident by the data address being modified by receiving a 0x03 (INT03).

It took me a while to find out that this was occuring because when I examined the location in the debugger, the debugger un-modified the breakpoint.

When the debugger was instructed to continue, it would re-insert the 0x03 into the data. i.e. you could notobserve the problem using the debugger.

Theonly way I could find this problem was by inserting diagnostic writes into the code.

Jim Dempsey

[jcl2]

Thanks for that Jim. It works, but doesn't really help. When I run it, it gives me a location in memset.asm, and I don't see how to easily get to the Fortran line where it happens. There is no Fortran source in the Call stack window. I also can't see the value it has changed to.

In the real case, I know from scattered write statements that a particular element of an array is getting a wrong value in a section of code between two writes. These writes are part of the built-in old-style debug system of our code. Any section of code between two writes may contain calls to many subroutines in many files.

In DevStudio6, it was easy to find where the bad line was because it would break every time that array element changed, and when you saw the bad value appear, you knew you had the right spot.

With this method, I know it has stopped because that memory location has changed, but I don't know where, or to what value.

I guess there are ways of finding out from the address and link maps, but I thought that way of working died out with the dinosaurs and that GUIs were supposed to do all that tedious stuff for you. I remember working out locations this way 20 years ago and I don't want to do it any more!

I also know I can keep on adding write statements to narrow the scope down until it is clear where the error is, but again it is much more efficient to let the Studio find the line for you.

I find it hard to believe that such a useful debug tool can really be so broken without a storm of protest or am I the only one who finds this feature useful?

I have raised this as an issue with Premier Support and await their reply!

John

[jim_dempsey]

The memset.asm is a result of the startup code (in the debugger)initializing the array. Place an execution breakpoint atthe first line of your main module before you set the memory change breakpoint (or just ignore the memset break). Then after reaching the first statement in your main module set your data change break point (or consider data change breaks valid after this point).

Jim