Debugging question: Is there any way to set a breakpoint based on a loop iteration??

[Ashley_Weinstein]

I have a large loop that I am trying to troubleshoot, with the error coming up at iteration #1875. Is there any way I can set a breakpoint in that loop at j=1874? Manually walking through the loop on a breakpoint inside the loop is taking too much time.

Now that I think about it, I can add an IF statement inside the existing loop along the following lines for debugging:

IF(j.GT.1870) THEN
dummy=dummy <-set breakpoint here
END IF

I'll just do this as it's easy to implement for debugging. If there is a better way of doing this please let me know!

[Ashley_Weinstein]

Interestingly enough, the breakpoint set in the IF statement did not work until I placed a breakpoint on an executable line just before the IF statement. After I ran the code up to this new breakpoint, I then removed the breakpoint and was able to continue onto the next breakpoint in the loop in the IF statement above.

[Steven_L_Intel1 · Accepted solution]

There are several ways to do this.

Set the breakpoint on a real statement you want a conditonal break on. You'll see the red circle appear to its left. Right click on this red circle, and several options will appear. One is "Condition...". If you select this, you can enter an expression that, when true, will cause the breakpoint to hit. For example, "j > 1870".

Another option is to do the above but select "Hit count" instead. Here you can select the number of times the breakpoint will hit before it stops execution.

A third option is to put in a statement that tests the condition you want and calls the Windows API routine DebugBreak when it hits. For example:

if (j .GT. 1870) call DebugBreak

You will need to add a "USE KERNEL32" just after the PROGRAM, SUBROUTINE or FUNCTION statement to make this available.

[Ashley_Weinstein]

Thanks Steve! I was trying to figure out if there were additional debugging options. One small step for programmers everywhere, one giant leap for me.

[Ashley_Weinstein]

Is there any way during Debug to have the compiler skip over calls to intrinsic functions like those contained in "crt0.c" without having to step out of them manually each time the compiler uses them?

[Steven_L_Intel1]

Um, don't step into them in the first place? The debugger doesn't know the difference between routines that are your code and those in a library. I usually use "Step Over" unless I know I want to step into a routine. Even then, sometimes there will be library calls as part of a call to a user routine, so some messiness here may be unavoidable.

[IanH]

There is a registry key that you can use to list the names of functions that you don't want the debugger to step into - see http://blogs.msdn.com/b/andypennell/archive/2004/02/06/69004.aspx. I've a recollection that I used to use this to stop calls into things like the stack check function when debugging Fortran.

[Ashley_Weinstein]

I'll check this out, thanks!

[Arjen_Markus]

A trick I use is:

if ( i .gt. 1870 ) then
write(*,*) 'Here'
endif

Then you can set the breakpoint on the write statement.

Regards,

Arjen

[Bernard]

You can set conditional break-point easily in WinDbg.You can do it on register value i.e. register which is used as a loop counter.

bp ["some address"] j ((@ecx >= "some value")&(@ecx <=" some value")) '';'gc'"

[Steven_L_Intel1]

Most readers of this forum would not be using WinDbg, which has no knowledge of Fortran.

[Bernard]

You can compile fortran code into executable and run it undsr windbg and fortran source code could be viewed in VS 2010.

[WSinc]

Like in an earlier article, if the breakpoint is really complicated, you have to insert code.
Example:

if(J==48 .and. K == 69 .or. L /= 12)then
continue
endif

And put the breakpoint on the CONTINUE statement.
But then you may have to disable the optimizer so that the CONTINUE statement does not get ignored.

Otherwise the little red dot gets put at God knows where.

[jimdempseyatthecove]

Argen,

I prefer to use a SAVE'd variable for the break test value. This way, I can change it during the run. (Initialized to value that will not break)

[Arjen_Markus]

Hey, I did not know that (or didn't realise you could do that). Nice to know.

Thanks,

Arjen