Code hangs when stepping through but not when left to run to next breakpt

[Stuart_M_]

I am stepping through some Fortran code (using VS 2005) and find it hangs at the IF statement in the attached code (which is true after the read - LOCAT is equal to zero). However, if I simply put a breakpoint at the next READ line (the last line of code attached) and let the code run uninterrupted from the IF statement to the READ statement then I have no problems. I have noticed that when stepping through the IF statement the DOS window is brought to the fore, at which point it hangs. This code is repeated three times, consecutively, using the same IF check but with different variables being updated to the value of CNSTNT, and each time the same problem and solution arises.

Can anybody shed some light on what is causing this? Thanks!

READ(501,1001)LOCAT,CNSTNT,FRMTIN,IPRN

1001 FORMAT(I10,F10.0,A20,I10)

IF(LOCAT .EQ. 0)THEN

THICK=CNSTNT

ELSEIF(LOCAT .GT. 0)THEN

C * Thick cannot be zero, because it appears in denominator

DO N=1,NMAX

READ(501,FRMTIN)(THICK(N,M), M=1,MMAX)

ENDDO

ENDIF

READ(501,1001)LOCAT,CNSTNT,FRMTIN,IPRN

[Steven_L_Intel1]

My guess is that the problem is the array assignment THICK=CNSTNT. I know there was an issue with stepping over a large array assignment - the way Visual Studio does stepping is that it stops on each instruction and then decides whether to continue, and there are a LOT of instructions in the array assignment.

My recollection is that we did something in the compiler or debugger interface to help this, but don't know the details. If Jeff Arnold reads this and replies, he would know. Otherwise I'll ask around.

Which compiler version are you using?

[jimdempseyatthecove]

Quoting - stubaan

I am stepping through some Fortran code (using VS 2005) and find it hangs at the IF statement in the attached code (which is true after the read - LOCAT is equal to zero). However, if I simply put a breakpoint at the next READ line (the last line of code attached) and let the code run uninterrupted from the IF statement to the READ statement then I have no problems. I have noticed that when stepping through the IF statement the DOS window is brought to the fore, at which point it hangs. This code is repeated three times, consecutively, using the same IF check but with different variables being updated to the value of CNSTNT, and each time the same problem and solution arises.

Can anybody shed some light on what is causing this? Thanks!

READ(501,1001)LOCAT,CNSTNT,FRMTIN,IPRN

1001 FORMAT(I10,F10.0,A20,I10)

IF(LOCAT .EQ. 0)THEN

THICK=CNSTNT

ELSEIF(LOCAT .GT. 0)THEN

C * Thick cannot be zero, because it appears in denominator

DO N=1,NMAX

READ(501,FRMTIN)(THICK(N,M), M=1,MMAX)

ENDDO

ENDIF

READ(501,1001)LOCAT,CNSTNT,FRMTIN,IPRN

Stubaan,

Read Steve's reply, then consider using

[cpp]READ(501,1001)LOCAT,CNSTNT,FRMTIN,IPRN
1001   FORMAT(I10,F10.0,A20,I10)
 IF(LOCAT .EQ. 0)THEN
 THICK=CNSTNT
 CONTINUE
ELSEIF(LOCAT .GT. 0)THEN
C * Thick cannot be zero, because it appears in denominator
 DO N=1,NMAX
 READ(501,FRMTIN)(THICK(N,M), M=1,MMAX)
 CONTINUE
ENDDO
ENDIF
 READ(501,1001)LOCAT,CNSTNT,FRMTIN,IPRN
[/cpp]

Place the break points on both the statement of interest and the immediatly following CONTINUE. Then use F5 to run to next break (in place of F10 to continue one step)

Jim Dempsey

[Stuart_M_]

Version 11.0.074

THICK is an array of 186 x 259, so it is fairly hefty... but I don't know how that compares relatively.

Perhaps this is related to another observation. I'm running Windows through Parallels on my Mac (quad-core, 4GB RAM though with only 1GB RAM allocated to Parallels) (though it certainly seems to slow down the rest of my system at times to the extent that I suspect it is actually using far more than just the 1 gig).

The code I am working with has recently, and inexplicably (to me! ;-), slowed down dramatically during debugging. I have lots of break points set, though all but a dozen at most are now disabled (not deleted though). Executing the code in debug is now so slow that the DOS window opens and remains blank for a few seconds, during which time I see some messages displayed in VS about loading System32 symbols. To experiment, I deleted all the breakpoints from another copy of the code and this delay disappears. I assume it's normal for debugging to be significantly slowed down with the addition of breakpoints, whether they're active or not?

Thanks!

[Steven_L_Intel1]

I've heard this from other users - that inactive breakpoints slow down debugging.

[jimdempseyatthecove]

It sounds like the problem is the time it takes to get the application to load and run to the first break point. This may be a problem with running Windows on MAC using Parallels. Each break point (used or not) at load time is going to require a file search to correlate the source file and line number to an object load point and offset (plus patch of code with INT03). Reducing the break points to aminimum might be your best choice (other that buying an actual Windows base platform).

Jim Dempsey

[Steven_L_Intel1]

Jeff confirmed for me that this is an inherent problem with most debuggers and is not Fortran-specific. The array assignment contains a loop and the debugger stops at each iteration in the loop to step through the branch and see if it is taken. There is nothing we can do about it.

[Stuart_M_]

Thanks a lot guys - doesn't change much but at least I understand better what is going on.

I tried adding CONTINUE where suggested above but had the same problem. Well, I assume it's the same problem - the code seems to hang but eventually steps through and I think previously I was impatient and assumed it had simply hung completely whereas it might have just been really dragging its heels.

Fortunately I don't really need all the breakpoints any longer, so my now more sparsely breakpointed version runs much faster.

Thanks!

[ZlamalJakub]

When I hang on when using "F10" on line with big array assignment (it can be only 10000 elements) I use "Break" button in debugger toolbar to stop application, then I set breakpoint after array assignment and then use "F5" to run over. It works nice to me.

Jakub