CVF -> IVF, inexplicable random crashes/data corruption

[inr]

I'm in the process of migrating our simulation package from Compaq Fortran 6.66b to VS2005/Intel Fortran 11.0. In CVF, everything compiles and runs smoothly. In IVF, I get hard to describe and random errors / behaviour. The first symptom was a random crash somewhere in the operating system (XP SP3), no stack/debug information available. Upon tracing, I found that at some point, data was corrupted (very similar to the typical array out of bounds error) - but array checking is enabled, and the exact same code sequence runs smoothly in CVF (I debugged on two different Laptops one in the old configuration, the other in the new). The corruption may also affect the debugger itself, e.g. when I set a conditional breakpoint, behaviour may change upon the nature of the condition (that is with "variable = value" as condition, the problem may occur at line 530, with "variable > (value - 1)", the problem occurs at line 560).

At this moment, I'm watching at the dissasembly of a procedure call, at the moment when the first argument is moved on the stack, some other variable changes its value. That first variable is an argument to the calling procedure itself, it's defined as REAL, as it is by the top level routine, and the callee. The debugger displays the type of that variable in all instances as REAL(4).

On one of the three systems where I installed the new environment, things do run. I had been experimenting with compiler/linker/debugger switches, at one point I wasn't able to run the debugger any more, I restored the project to some prior state, and magically, the error didn't occur any more. When I copy this exact project to one of the other two machines, it fails.

[Steven_L_Intel1]

This sounds like stack corruption. Did you convert the project using the Extract Compaq Visual Fortran Project Items option? Are you using any external libraries that were built for use with CVF?

[inr]

Quoting - Steve Lionel (Intel)

This sounds like stack corruption. Did you convert the project using the Extract Compaq Visual Fortran Project Items option? Are you using any external libraries that were built for use with CVF?

2x no. No, I rebuilt the project(s) from scratch (copying only the source files from the old environment), and no, I don't use any external libraries.

[ZlamalJakub]

Problem can be caused by different storage of variables in memory. In CVF there is I think default variable storage in memory (SAVE), in IVF on stack.

Is not problem with some uninitialised variable (In first call of routine set to something but in second call is again uninitialised)?

I have had similar problems with my application when migrating to IVF.

Problem with changing variables during debugging disassembly can be caused by changing stack pointer (I think it is esp register) during calling sequence. Correct variable values are displayed after all arguments are passed i think.


Jakub

[inr]

Quoting - Quba

Problem can be caused by different storage of variables in memory. In CVF there is I think default variable storage in memory (SAVE), in IVF on stack.

Is not problem with some uninitialised variable (In first call of routine set to something but in second call is again uninitialised)?

I have had similar problems with my application when migrating to IVF.

Problem with changing variables during debugging disassembly can be caused by changing stack pointer (I think it is esp register) during calling sequence. Correct variable values are displayed after all arguments are passed i think.


Jakub

Thanks for the good ideas. I tried Project Properties->Fortran->Data->Local Variable Storage->All Variables SAVE (/Qsave), the crash happens at another place, but quite close to the "usual" location.

No, I don't think it's a not initialized variable - the problem may occur on the first call to some subroutine, or (in a very similar context) on the 35th call of the same routine.

The variable value change on calling a subroutine is not a phantom, the other variable is destroyed for real - at first I thought this happend during the call, but it actually happens when the first parameter is put on the stack (this normally means that the stack pointer is corrupted at that moment, so the real problem is somewhere prior to this).

I regularly fail when I try to understand why it was running under CF, and why I have one of three configurations where it's fine too.

[Steven_L_Intel1]

If you change the property External Procedures > Calling Convention to "CVF" does it still fail?

[IanH]

Possible red-herring, but this may help explain some of the symptoms and/or assist to find the underlying problem.

When running in the debugger under VS2005 (don't know about other VS versions, don't know whether IVF integration version is relevant), if you have an assignment (var_name=0) as the expression for a conditional breakpoint then the variable being tested will actually have its value changed when execution reaches the breakpoint. But whether the breakpoint then "fires" (stops execution) depends on the value being assigned, I think with true/false according to C rules - so if you assign a zero to the variable the breakpoint does not fire (but note the value is still changed!).

I've no idea whether this is intentional/by design or not, but it can result in some very confusing debugging behaviour.

I point this out because in your original post your first conditional as written is assignment, while the second is a proper conditional expression. If that's not a typo then try your debugging using '==' or '.eq.' instead.

Stupid little program to demonstrate. To see the behaviour it must be run under the debugger (ie press F5 to start, not Ctrl-F5) and with no optimisation (as per a typical "Debug" configuration).

[plain]PROGRAM DebugTest
  IMPLICIT NONE
  INTEGER a  
  !****
  a = 1  
  WRITE (*, 100) 'Hello, a is ', a
  ! Set a breakpoint on the line below with condition "a=2" or "a=0"
  IF (a == 2) THEN    
    WRITE (*, 100) 'In the IF, a is ', a
  END IF
  WRITE (*, 100) 'At the end, a is ', a
  ! Put an unconditional breakpoint below so you can see program output.
  WRITE (*, 100) 'Goodbye!'
  100 FORMAT(A,:,I0)
END PROGRAM DebugTest[/plain]