Release vs debug configuration, again

[Intel_C_Intel]

Well folks, here I am again with my recurring problems with debug vs release configurations and am open to suggestions on how to track down an error in my program.

With the release configuration, I am getting the following:

Program exception - access violation
Routine Line
Kinetics 8708

Lines 8700 to 8708 in kinetics

 
DO I=IU,ID 
  DOSS(KT,I) = 0.0 
  DO K=KT,KB(I) 
     DO JA=1,NAL 
      DOAP(K,I) = DOAP(K,I)+AGR(K,I,JA)*ALG(K,I,JA)*O2AG(JW) 
      DOAR(K,I) = DOAR(K,I)+ARR(K,I,JA)+ALG(K,I,JA)*O2AR(JW) 
    END DO 
    DOPOM(K,I) = (LPOMD(K,I)+RPOMD(K,I))*O2OM(JW) 
    DODOM(K,I) = (LDOMD(K,I)+RDOMD(K,I))*O2OM(JW)  !line 8708 

As you can see, line 8707 contains O2OM(JW) and I am not getting an access violation in 8707, so the problem must be in the accessing of DODOM(K,I), LDOMD(K,I), or RDOMD(K,I). However, when I go into the debugger, I have no problem accessing the values of any of these variables nor do I have a problem printing out the RHS of line 8708. All of the (K,I) variables have been allocated previously. When I am in the debugger, all the arrays have been allocated to KMX and IMX and the values for K and I are within the bounds of the arrays.

Question - what good is a debugger if you can't reproduce the error that caused you to go into the debugger in the first place? Joseph Heller would really enjoy this.

Anyway, does anyone have any suggestions? I hate to resort to write statements in the code as it takes 9 minutes to compile the code on my 933 MHz machine, but will have to unless anyone can come up with some help.

Tom

[Steven_L_Intel1]

What I would do is, in the Debug configuration, start raising the optimization level one step at a time to see if you can reproduce the problem with optimization. The problem is that as the optimization level increases, the usefulness of the debugger decreases.

The other thing can be that the actual problem was created elsewhere, but didn't become apparent until the line shown. If these are allocatable arrays, perhaps something overwrites their array descriptor.

These can be difficult to track down, I admit.

Steve

[Intel_C_Intel]

Steve,

Thanks for the tips. I have compiled under the debug configuration and increased the optimization level to global, which now reproduces the problem. However, I now have a write statement immediately before the offending line that writes out the values of K, I, DODOM(K,i), LDOMD(K,I), RDOMD(K,I), and O2OM(JW) to the console (all the variables in line 8708).

The values are K=18,I= 2, DODOM(K,I)=0.0, LDOMD(K,I)=4.032e-7, RDOMD(K,I)=3.36e-9, AND O2OM(JW)=1.4 as appear in the console window and the watch window (except for K in the watch window which says "cannot view register variable), so the program is able to access all the variables correctly during the write statement without the access violation error.

But if I continue stepping over lines, I get the access violation error (the global optimization screwed up where stepping over lines takes place in the source code as you said would happen). If K=18 and I=2 as printed to the console window, which are within the array bounds of DODOM, LDOMD, and RDOMD, then what could be going on to give the access violation?

Any further helpful hints?

Tom

[Steven_L_Intel1]

It's really difficult to say without seeing the actual program. If you'd like us to take a look, send us a ZIP archive of the project, and any data files needed, to vf-support@compaq.com. Be sure to include a complete problem description and attach a filled-out copy of BUGREPRT.TXT, or use VF Reporter.

Steve

[Intel_C_Intel]

Steve,

Thanks for all the help - you are a good man. I finally tracked it down to using the same variable name (JBOD) for a DO loop counter in a subroutine entry section that was passed as an argument in a previous entry section of the subroutine. Apparently, the compiler belches in this instance, although it seems like it should be OK for me to do this. Does this behavior adhere to the FORTRAN standard?

Tom

[Steven_L_Intel1]

The Fortran standard requires that if you reference a variable which appears in any argument list to any entry point to a given routine, that you must have entered through an entry point which has that variable in its argument list. So, for example, if you had:

subroutine sub (i)
... do some stuff
return
entry sub2 (j)
do i=1,10
...

This would be disallowed, since the path to the DO did not come in through sub2.

In some older Fortran compilers, you could get away with this error, but not in most of today's compilers.

Steve

[Intel_C_Intel]

Steve,

Wouldn't it be possible to check for this during compilation? Also, what the heck has gone on with the fonts in this forum? My over 50 eyes can barely read it with my monitor set to 1920 x 1440.

Tom

[Steven_L_Intel1]

Whether or not the compiler can check depends on the control flow in the program. An interesting idea, though...

As for the fonts - if you're not using IE6, they're about the same size as they were before, at least they're supposed to be. I have a complaint into the forum programmers that the HTML they're now generating is a bit squirrely - IE6 doesn't like it at all.

Does it look similar to the font sizes at the compaq.com home page?

Steve

[Intel_C_Intel]

The forum font size has definitely gotten much smaller. It is difficult to read.
IE 5.5, Thinkpad A20p, display settings 1280 x 1040

-JT

[Intel_C_Intel]

Steve,

I'm using IE 5.0 on my home machine and 5.5 on my work machine. FYI, the actual error was not on line 8708 but on 8709, which is why it took me so long to track it down. Again, thanks for the help.

Tom