Large project -- getting an access violation with certain compiler settings.
If try to put it in debugger or add any checks (i.e. array bounds, etc), it runs. Adding /fpe:0 and it runs.
I'd like to say it's a compiler issue but?
链接已复制
Different architectures mean different memory layout, different instructions, etc. "faulting IP" means the instruction pointer of where the error occurred. Technically, you have that already as its in the traceback.
So now we know that the source line of the error is:
5409 FinalZoneSizing(CtrlZoneNum)%CoolZoneRetTempSeq(TimeStepIndex) = &
5410 FinalZoneSizing(CtrlZoneNum)%CoolZoneTempSeq(TimeStepIndex) + RetTempRise * &
>5411 (1.d0/(1.d0+TermUnitSizing(CtrlZoneNum)%InducRat))
but we don't know which part of this statement is the problem. realistically, it will be either FinalZoneSizing(CtrlZoneNum)%CoolZoneRetTempSeq(TimeStepIndex) or TermUnitSizing(CtrlZoneNum)%InducRat). What I would do, as an experiment, is declare a temporary variable, say, temp, and assign TermUnitSizing(CtrlZoneNum)%InducRat)) to it before this statement, then substitute temp in the expression. Do you still get the error? Does the error move? If the error still exists but doesn't move, then FinalZoneSizing(CtrlZoneNum)%CoolZoneRetTempSeq(TimeStepIndex) is probably the problem - you'd have to figure out which part of this is wrong.
Where would you like me to put it? I can zip up the object/source/project. It will be quite large.
I have to backtrack on my previous statement -- it does now terminate where it says:
temp=termunitsizing
I had inadvertently added a "if (allocated(termunitsizing)) stop" statement above that -- and it caused it to run.
maybe i can work with it further.
I am building with F2008 semantics. I did manage to get the compiler / debugger to show that the index of that structure was 0 -- however it is inside a specific loop with that index as a loop control variable.
It may take a while to make it so you can see it -- but to me, it seems like a compiler bug.
lklawrie wrote:
"faulting ip"? Please be clear in what you are requiring/suggesting. And why is it fine in Win32 but not x64?
Sorry for not providing enough expalnation.Faulting ip = instruction pointer which caused some fault or exception.
Please proceed exactly as Steve advised.Run your program under debugger(first source-level) step in on every instruction and inspect the memory beign read/written pay attention to any pointer dereferences.If this will not be helpful machine code level debugging with the help of application verifier should be used to test your app.
Issue 698745 posted. Steve, it's set to run with break at the place where it will most likely crash.
No one asked for compiler settings. Compiler settings:
Compiler:
/nologo /debug:minimal /O2 /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc90.pdb" /traceback /libs:static /threads /c
pasted to command line window (from others)
/nologo /fpp /stand:f08 /Qdiag-disable:5268 /fpscomp:none /nogen-interfaces /F8388608 /DWINDOWS /O2 /DNDEBUG
Linker:
/OUT:"x64\Release\Console3.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"C:\Users\lklawrie\Documents\Visual Studio 2008\Projects\Console3\x64\Release\Console3.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\lklawrie\Documents\Visual Studio 2008\Projects\Console3\x64\Release\Console3.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Users\lklawrie\Documents\Visual Studio 2008\Projects\Console3\x64\Release\Console3.lib" /STACK:8388608
/fpe:0 changes the choice of instructions used. 3 is the default and the only other choice is 1, which hardly anyone bothers with. (2 was suppported with DEC compilers.) It does seem that most anything that changes the instruction stream makes the problem "go away" based on what Linda has said to date.
