out of control DO loop

[jajdavid]

I have a situation where a certain DO loop runs out of control causing an eventual access violationunless one of the following is true:

1. optimizer set to non-zero

2. add a WRITE(6,*) statement is anothersubroutine that is called by the offending routine.

3. remove fltconsistency ( nofltconsistency)

4. skip a single statement that is perfectly OK

5. skip another bunch of statements that are perfectly OK

When any of the above are true, the program executes perfectly.

So my question is: can an error in my code somehow alter the instructions that are being executed without there being an access violation?

The only thing I could think of was perhaps I am running out of stack space. If so how does one specify more stack space?

[Steven_L_Intel1]

The answer to your question is "Yes - an error elsewhere in your code can cause erratic behavior". Common csauses are "memory stomping" (writing to memory outside the bounds of the variable), stack corruption (often when calling STDCALL routines when you haven't told the compiler they are STDCALL), type mismatches, etc. The changes you describe are all indicative of errors that are sensitive to memory layout.

[jajdavid]

Is there any way to catch memory errors?

[jajdavid]

Here's somethingone can ponder over the holidays given a few spare moments:

Let's say you have a stack error - maybe associated with an errant DO loop.

So here's how to catch it:

1. Find out exactly when the stack error begins its little nasty journey. You can do that by
putting in counters that record the count when things first seem to go bad. Let's say
when COUNTER = BAD, that is when the nasty stuff starts happening.

2. Put in the following code

DO I=0,0
IF ( COUNTER .EQ. BAD ) GOTO 1000
END DO

Make sure thelabel 1000 branches around enough code to includethe suspect code, so it is not executed

3. Move the DO loop around the code, testing it to see when the program
crasheswhen it is at a certain position and when it doesn't

4. Guess what? You found the exact code that is bad. I.E. The bad code has to be
between when the test DO loop allows the program to proceed and when
the DO loop fails to stop the error.

[Steven_L_Intel1]

The combination of Visual Fortran Composer XE 2011 and Intel Inspector XE 2011 can detect various types of memory access errors, including leaks. I don't know for sure that it would catch "memory stomping" errors but it's worth a try. You can download a 30-day free trial.