odd problem

[lklawrie]

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?

[bmchenry]

You need to provide some sample error messages. It appears to work in 'debug' only, so could it be you've set a release directory in a location that is for admin only and you aren't running with admin privileges? Or some other resource you’ve specified isn’t available to you?

[lklawrie]

No, you misunderstand.  It does run in Debug, but it also runs in "release" if I add, say, /check:bounds or /check:uninit.

The error from traceback (added but problem still exists):

forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
Console1.exe       0000000140EDFF3D  SIMAIRSERVINGZONE        5408  SimAirServingZones.f90
Console1.exe       0000000141195E0C  SIZINGMANAGER_mp_         521  SizingManager.f90
Console1.exe       00000001411A72E8  SIMULATIONMANAGER         186  SimulationManager.f90
Console1.exe       00000001411BFCB0  MAIN__                    421  EnergyPlus.f90
Console1.exe       00000001412BE0DC  Unknown               Unknown  Unknown
Console1.exe       00000001412980FF  Unknown               Unknown  Unknown
kernel32.dll       000000007737652D  Unknown               Unknown  Unknown
ntdll.dll          00000000774AC521  Unknown               Unknown  Unknown

[lklawrie]

FYI - as we wait for the window with the error to be posted.  This was on x64.  On win32, same settings do not produce an error.

[Steven_L_Intel1]

Adding any option that changes the sequence of instructions, or layout of data in memory, can "move" a problem. Each of the options you mention significantly affects the code. A Debug configuration disables optimizations changing things much more.

You at least have the line of code where the error occurs. You might be able to add some instrumentation of your own (aka PRINT statements) to see if you can figure out what exactly the problem is. An uninitialized variable would be my guess. Running the program under Intel Inspector XE's memory analysis might provide a clue.

[lklawrie]

As soon as you add a print statement the problem goes away.  I will try inspector.  Note -- this is only the x64 version, not the win32 version (same compiler).

My other post didn't get posted (that showed the line of code where it happened?  Is it lost in cyberspace?

[Steven_L_Intel1]

Your post may have been held for moderation - though I can't see it myself.

There are a couple of different strategies I use when presented with a case like this.  One is to do "divide and conquer" with optimization settings, disabling optimization on half the sources and see if the problem goes away, and then refining so I have the minimal number of sources where optimization needs to be on to see the problem. I then try a debug configuration with just those sources set for optimization, and turn off the other run-time checks.

Other times I'll look at the instruction stream where the access violation occurs by running under the debugger in Release mode - this sometimes gives me a clue as to what is going on. I recognize that this won't be usable by many people.

[lklawrie]

Moderated post finally showed up.  Not worth too much to try to figure out a compiler problem with the procedures you've suggested as we can just turn on the /check:uninit and the problem goes away.

It also goes away if the code is rewritten at that point to be more explicit (though same code is in previous lines).  But that's hard to tell developers to do -- write it one way in part and differently in another.

[mecej4]

lklawrie wrote:
just turn on the /check:uninit and the problem goes away

I'd be more cautious, and conclude that the pesky bug(s) just went underground instead of "going away". The bug may come back in the future and do havoc.

[Bernard]

Access Violation types of bugs can manifest at random times it dependes when your code will reference for example unaccessible memory or will try to call unmapped code in some dll.

[lklawrie]

Sure, okay - mecej4 and ilyapolak -- I would love to track it down (if it is a bug in the code) but it runs without error on win32, and seems elusive if you can't find out what the problem is -- print statements don't show it, etc.  What would you suggest?

FYI, using other compilers to try to turn it up did not help either.

[Bernard]

Who is catching Access violation error?Is this werfault.exe process?

[Bernard]

If you really would like to investigate that issue then I recommend to instal application verifier and perform stress test of your app.

[lklawrie]

See above for the traceback from the execution.  Application verifier?  Does that have another name?

[Bernard]

lklawrie wrote:

See above for the traceback from the execution.  Application verifier?  Does that have another name?

Traceback is not complete.Aplication Verifier is the actual name of software recommended by me.If you want give it try:)

[andrew_4619]

I thought the Visual Studio application verifier only work with VC++ projects?

[jimdempseyatthecove]

>> This was on x64.  On win32, same settings do not produce an error.

When the code runs as x32 but not (well) as x64 then one of the causes is use of wrong sized arguments to library calls. In particular use of "integer" in place of "integer(HANDLE)" or "integer(someOtherSizeForType)". Many of these errors in programming can be found with the gen interfaces warn interfaces compiler options.

Jim Dempsey

[Bernard]

app4619 wrote:

I thought the Visual Studio application verifier only work with VC++ projects?

What VS application verifier are you talking about?

Application Verifier is standalone application and it is used afaik to perform stress tests of software at MS.

[Bernard]

jimdempseyatthecove wrote:

>> This was on x64.  On win32, same settings do not produce an error.

When the code runs as x32 but not (well) as x64 then one of the causes is use of wrong sized arguments to library calls. In particular use of "integer" in place of "integer(HANDLE)" or "integer(someOtherSizeForType)". Many of these errors in programming can be found with the gen interfaces warn interfaces compiler options.

Jim Dempsey

Should not that be handled by WOW64 layer?

[lklawrie]

FYI, Inspector sees the access violation at the line but does not give much information:

P2: Error: Invalid memory access
 P2.3: Invalid memory access: New
  C:\Working\EnergyPlus\SourceCode\EnergyPlus\SimAirServingZones.f90(5411): Error X4: Read: Function SIMAIRSERVINGZONES_mp_UPDATESYSSIZING: Module C:\Users\lklawrie\Documents\Visual Studio 2008\Projects\Console2\x64\Release\Console2.exe
  Code snippet:
   5409              FinalZoneSizing(CtrlZoneNum)%CoolZoneRetTempSeq(TimeStepIndex) = &
   5410                FinalZoneSizing(CtrlZoneNum)%CoolZoneTempSeq(TimeStepIndex) + RetTempRise * &
  >5411               (1.d0/(1.d0+TermUnitSizing(CtrlZoneNum)%InducRat))
   5412            END IF
   5413            RetTempRise = FinalZoneSizing(CtrlZoneNum)%HeatZoneRetTempSeq(TimeStepIndex) - &

  Stack (1 of 1 instance(s))
  >Console2.exe!SIMAIRSERVINGZONES_mp_UPDATESYSSIZING - C:\Working\EnergyPlus\SourceCode\EnergyPlus\SimAirServingZones.f90:5411
   Console2.exe!SIZINGMANAGER_mp_MANAGESIZING - C:\Working\EnergyPlus\SourceCode\EnergyPlus\SizingManager.f90:521
   Console2.exe!SIMULATIONMANAGER_mp_MANAGESIMULATION - C:\Working\EnergyPlus\SourceCode\EnergyPlus\SimulationManager.f90:186
   Console2.exe!MAIN__ - C:\Working\EnergyPlus\SourceCode\EnergyPlus\EnergyPlus.f90:421
   Console2.exe!main - C:\Users\lklawrie\Documents\Visual Studio 2008\Projects\Console2\x64\Release\Console2.exe:0x00000000012F3877
   Console2.exe!_tmainCRTStartup - f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:266
   kernel32.dll!BaseThreadInitThunk - C:\windows\system32\kernel32.dll:0x000000000001652B
   ntdll.dll!RtlUserThreadStart - C:\windows\SYSTEM32\ntdll.dll:0x000000000002C51F

P1: Critical: Unhandled application exception
 P1.4: Unhandled application exception: New
  C:\Working\EnergyPlus\SourceCode\EnergyPlus\SizingManager.f90(521): Critical X5: Exception: Function SIZINGMANAGER_mp_MANAGESIZING: Module C:\Users\lklawrie\Documents\Visual Studio 2008\Projects\Console2\x64\Release\Console2.exe
  Code snippet:
   519 
   520      IF (NumSizingPeriodsPerformed > 0) THEN
  >521        CALL UpdateSysSizing(EndSysSizingCalc)
   522        SysSizingRunDone = .TRUE.
   523      ELSE

  Stack (1 of 1 instance(s))
  >ntdll.dll!MD5Final - C:\windows\SYSTEM32\ntdll.dll:0x00000000000943B6
   ntdll.dll!_C_specific_handler - C:\windows\SYSTEM32\ntdll.dll:0x00000000000185A6
   ntdll.dll!RtlDecodePointer - C:\windows\SYSTEM32\ntdll.dll:0x0000000000029D09
   ntdll.dll!RtlUnwindEx - C:\windows\SYSTEM32\ntdll.dll:0x00000000000191AA
   ntdll.dll!KiUserExceptionDispatcher - C:\windows\SYSTEM32\ntdll.dll:0x0000000000051273
   Console2.exe!SIZINGMANAGER_mp_MANAGESIZING - C:\Working\EnergyPlus\SourceCode\EnergyPlus\SizingManager.f90:521
   Console2.exe!SIMULATIONMANAGER_mp_MANAGESIMULATION - C:\Working\EnergyPlus\SourceCode\EnergyPlus\SimulationManager.f90:186
   Console2.exe!MAIN__ - C:\Working\EnergyPlus\SourceCode\EnergyPlus\EnergyPlus.f90:421
   Console2.exe!main - C:\Users\lklawrie\Documents\Visual Studio 2008\Projects\Console2\x64\Release\Console2.exe:0x00000000012F3877
   Console2.exe!_tmainCRTStartup - f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:266
   kernel32.dll!BaseThreadInitThunk - C:\windows\system32\kernel32.dll:0x000000000001652B
   ntdll.dll!RtlUserThreadStart - C:\windows\SYSTEM32\ntdll.dll:0x000000000002C51F

I added a check for allocated TermUnitSizing in the IF Block but of course then the whole code runs. (actually, printed not just a check)

/warn:interfaces did not yield anything.

[Bernard]

You have access violation bug and Inspector will not give you the clearest picture.You need to know what is the faulting ip and stop on faulting ip and inspect thread context content.