Why can't I debug the START of a DO LOOP?

[billsinclaol_com]

In this example, I want to set a breakpoint at the DO statement:


Do I=1,100
Etc.
Etc.
End do

But it takes a breakpoint 100 times no matter what I do,
even when the little dot is ON the Do statement.
I didNOT want the break to be on the statement after the Do statement.
So I put a CONTINUE statement BEFORE the Do loop, and
it will NOT set the breakpoint there. It wants to jump ahead.

I thought we didn't have to put JUNK statements in to get it to break
where we want it?

Is that asking too much?

[IanH]

I don't see this behaviour with VS2005 and ifort 12.0.5 with an out-of-the box debug configuration - the breakpoint is only hit once at the instruction that loads the do variable with its initial value. My test program attached below, perhaps the behaviour changes for your example, but in order to advise further you need to provide a more complete sample.

[fortran]PROGRAM DoLoop
  IMPLICIT NONE  
  INTEGER :: i  
  DO i = 1, 10      ! BP here
    PRINT *, i
  END DO
END PROGRAM DoLoop[/fortran]

You can set conditions, hit counts, filters, etc on break points - after you have set the breakpoint on a line right click on the line and then select the "Breakpoint" menu item and then look at the options in the resulting submenu (once a breakpoint has been set you can also use the break point window to manage this sort of stuff). A condition on the breakpoint (use the syntax of a Fortran logical expression - for example "i .EQ. 1") may perhaps prevent multiple "breaks".

Evaluation of the condition every time the code passes over the break point will increase runtime (even if the debugger then decides not to break the code), so for deeply nested loops it may be appropriate to set breakpoints at outer levels and only enable breakpoints and conditions at inner levels once the outer level loops have reached an appropriate iteration.

You can also set breapoints on individual machine instructions from the disassembly window after your program has stopped at its first breakpoint.

Note that in some cases a single fortran source line (that perhaps invokes multiple functions or complicated array references) may correspond to multiple instructions - when this is the case the breakpoints window will show a little plus next to the breakpoint and, if expanded, a tree-like heirarchy of child breakpoints associated with the fortran source line once execution of your program has started. This can give you finer control over which particular sequence of instructions you want the breakpoint to correspond to (though working out which child-breakpoint is the one that you want may require inspection of the disassembly).

[WSinc]

Hi Ian -
Thanks for your tips -

I have VS 2008, so maybe there is an interaction that you don't have with VS 2005.

Like I said earlier, in order to get it to break BEFORE the DO loop starts, I have
to insert a "junk" statement, i.e.

ijunk=1-ijunk

which effectivlely does nothing, but a CONTINUE doesn't work. At least the debugger does not
know how to put a breakpoint in it. Maybe I should look to see if ANY code is generated.

When the breakpoint DOES occur, does the arrow ALWAYS POINT to the next statement? What if the breakpoint is on a GO TO Statement, for example?

I was wondering if it's possible to control the handling of breakpoints from EXECUTION of the code -
in other words, is there a statement I could execute that would enable or disable a breakpoint?
That would make it more flexible in complicated situations.

I was also wondering - in the case of a LOGICAL variable, how do I set it when the variable is either TRUE or FALSE? Of course, I can set when it changes value. I could not find the right syntax.

[John_B__Walter]

I'm using VS2008, and have no problem setting a breakpoint on the DO line, so long as there is something real in the loop, an executable statement, not just a continue.

I don't think the compiler produces any actual NOP instructions that you could put a breakpoint on.

[billsinclaol_com]

The DO loop had more than 20 executable instructions in it.

I had to put the CONTINUE statement BEFORE the Do LOOP so that I could breakpoint
it before it was initiated.

Setting the cursor to the DO statement and hitting F9 puts the breakpoint INSIDE the DO LOOP
where I don't want it.

If Continue doesn't work, then I have to insert something like:

ICRAP = 1 - ICRAP

or : XCRAP = 0.0
which does nothing, but at least it generates executable code.

I don't see why this should be necessary with a properly designed
debugger.

[Steven_L_Intel1]

Bill, how about you post a code example that demonstrates the problem. It's not one I've seen before.

[WSinc]

Subroutine inquestion -
Do Loop starting line 23 "Do IMOVE" etc.

I can't BP the start of the Do LOOP, it
excutes the BP multiple times.

[Steven_L_Intel1]

This is missing too much to be able to build and test. Please provide a buildable and runnable example. Please also show the compile options you are using (from the Command Line property page.)

[billsinclaol_com]

IS there a way to just upload the whole project at once?

[Steven_L_Intel1]

Do a Build > Clean and then Zip the project folder. Attach the Zip.

[Les_Neilson]

I always thought this was "normal" behaviour. The breakpoint stops at the DO, and pressing F5 takes it round the loop incrementing/decrementing the loop index each time. I presume this is what you mean by "executes the BP multiple times" ?
Ipresume therefore that you want it to stop at theDOstatement only once (i.e. the first time) and pressing F5 will just execute the do loop?
Is it possible for youto make the BP a conditional BP?
Maybe show the dissassembly code and add a BP in there? (I've not done it myself so I'm not sure it is feasible)

Les

[WSinc]

It can't find the ZIP file.

It pretends there is nothing there.

Is this some kind of security thing?

[Steven_L_Intel1]

"It"? If you uploaded a file, you then have to click the "Attach" button to attach it to your post. You can still do this - click on Add Files, click on the folder you created, click again on the ZIP file, and then click the Attach button.

[WSinc]

OK, here goes again -

[Steven_L_Intel1]

Which of the two projects in that ZIP is the one at issue and where is the DO loop?

[WSinc]

The prjoect is CONSOLE1, and the BP is at line 23 of
genmove_1.f90

Sorry I forgot about the pther project -
it generats primes used by CONSOLE1, but the file is already there.
All the data files should be included as well.

[Steven_L_Intel1]

I get this when I run it - before the DO loop in question is hit:

[plain]forrtl: severe (408): fort: (2): Subscript #3 of the array BOARDS has value 47 which is greater than the upper bound of 36

Image              PC        Routine            Line        Source
Console1.exe       004BF100  Unknown               Unknown  Unknown
Console1.exe       00432D41  Unknown               Unknown  Unknown
KERNELBASE.dll     764A3FC3  Unknown               Unknown  Unknown
Console1.exe       004105C3  Unknown               Unknown  Unknown
Console1.exe       004109F3  Unknown               Unknown  Unknown
Console1.exe       0041124C  Unknown               Unknown  Unknown
Console1.exe       0040610F  _GENMOVE_0                 18  genmove_0.f90
Console1.exe       00407CAC  _MAIN__                    55  sudoku_6x6.f90[/plain]

The subscript value changes from run to run, suggesting to me you have an unintialized variable or other memory access error.

[WSinc]

HMM - I AM WONDERING WHY IT RUNS TO COMPLETION ON MY SYSTEM.

Does it have anying to do with the OS environment? I have never seen this on my end.

That routine where you encountered this is BEFORE the subroutine we were talking about.

Can you try a rebuild on your end, see if it does the same thing?

I sent you the exact same source code I was using. I'm wondering if the input data file
was corrupted, that could cause this. It's referenced by LGU #2 --> sudoku_inp.txt

Or maybe send me a copy of what came out on your end.

Yours; Bill S.

[jimdempseyatthecove]

Les,

Consider:

DO I=X,Y-Z
...
Y=SomethingElse
...
END DO

The FORTRAN rules evaluates the iteration space, once, prior to entry of loop body, producing an iteration count (and step). This count is then used for iteration purposes. Unlike a C/C++ for loop, modifying the variables in the termination expression has no effect on the iteration count.

Therefore, what would you expect when you place the break point on the DO statement?
a) break once on evaluation of iteration space?
b) break on evaluation of termination condition?
c) break prior to execution of each loop?

Since break point typically breaks at a statement _prior_ to execution it should result in expectation a).

If you want b), then presumably you place the break at the END DO statement (since that is where the iteration termination inc/dec and/or test occurs.

If you want c) then place the break at the first statement after (inside)the DO loop.

Jim Dempsey

[Steven_L_Intel1]

As you uploaded a ZIP file, what I have is exactly what you sent. In genmove_0, the line:

loc2=loc(boards(1,1,level))

level is an uninitialized local variable. Perhaps you meant to use ilev here instead - I don't know.

I ran your code through Parallel Studio XE's Static Security Analysis and it found this and a number of other possible issues (not all of these may be real problems):

ID Problem Sources State Weight Category
P12 SC_2143 genmove_0.f90 New 100 CAT_UNINITIALIZED
genmove_0.f90(18): error #12143: "LEVEL" is uninitialized

P3 SC_2049 bdfind.f90 New 70 CAT_BUFFER_OVERFLOW
bdfind.f90(21): error #12049: buffer overflow: array index of "STLINK" is possibly outside the bounds; array "STLINK" of size (1:36) can be indexed by value 37

P4 SC_2049 bdstore.f90 New 70 CAT_BUFFER_OVERFLOW
bdstore.f90(23): error #12049: buffer overflow: array index of "STLINK" is possibly outside the bounds; array "STLINK" of size (1:36) can be indexed by value 37

P5 SC_2049 bdstore.f90 New 70 CAT_BUFFER_OVERFLOW
bdstore.f90(26): error #12049: buffer overflow: array index of "STLINK" is possibly outside the bounds; array "STLINK" of size (1:36) can be indexed by value 37

P6 SC_2049 bdstore.f90 New 70 CAT_BUFFER_OVERFLOW
bdstore.f90(27): error #12049: buffer overflow: array index of "LAST" is possibly outside the bounds; array "LAST" of size (1:36) can be indexed by value 37

P7 SC_2049 bdstore.f90 New 70 CAT_BUFFER_OVERFLOW
bdstore.f90(34): error #12049: buffer overflow: array index of "LAST" is possibly outside the bounds; array "LAST" of size (1:36) can be indexed by value 37

P8 SC_2049 bdstore.f90 New 70 CAT_BUFFER_OVERFLOW
bdstore.f90(39): error #12049: buffer overflow: array index of "LAST" is possibly outside the bounds; array "LAST" of size (1:36) can be indexed by value 37

P16 SC_2305 bhash.f90 New 55 CAT_UNVALIDATED_INPUT
bhash.f90(15): error #12305: unvalidated value is received from call to an external function at (file:bhash.f90 line:13) which can be used in index expression of "PRIMES"

P9 SC_2082 sudoku_6x6.f90 New 10 CAT_MISCELLANEOUS
sudoku_6x6.f90(47): error #12082: infinite loop

P14 SC_2178 bhash.f90 New 8 CAT_REDUNDANT_CODE
bhash.f90(14): warning #12178: this value of "KK" isn't used in the program

P15 SC_2178 sudoku_6x6.f90 New 8 CAT_REDUNDANT_CODE
sudoku_6x6.f90(33): warning #12178: this value of "DEAD" isn't used in the program

P10 SC_2090 bdfind.f90; bdstore.f90 New 1 CAT_DECLARATION
bdfind.f90(3): error #12090: inconsistent declaration of variable "CREC" (wrong type). See (file:bdstore.f90 line:44)

P11 SC_2090 bdstore.f90 New 1 CAT_DECLARATION
bdstore.f90(2): error #12090: inconsistent declaration of variable "CREC" (wrong type). See (file:bdstore.f90 line:44)

P13 SC_2135 copyb.f90 New 1 CAT_UNREACHABLE_CODE
copyb.f90(1): warning #12135: procedure "COPYB" is never called

[WSinc]

I thought that putting the BP on the DO statement would simply
cause it to break before the iteration starts, and when the counter
is initialized. At least that was the case eons ago, when COMPAQ had
the compiler.

Of course, DO WHILE has a different meaning than DO UNTIL. But
expectation (a) is what I expected.

If I want to look at the compiled machine code, what is the command for that?
How do I get it to point to the exact machine location where it would stop?