Access violation, in win32 release ONLY

[danielsue]

Hi All,

I ran into a tricky problem. The program runs well when build in win32 debug, x64 debug, x64 release, but cause access violation in win32 release.

I checked carefully on the compilation options, they are the same. How does this error come?

The configure files are as follows:

        <Configuration Name="Debug|Win32">
                <Tool Name="VFFortranCompilerTool" AdditionalOptions="/Z7 /fp:strict" SuppressStartupBanner="true" DebugInformationFormat="debugEnabled" Optimization="optimizeDisabled" Preprocess="preprocessYes" EnableRecursion="true" WarnInterfaces="true" Traceback="true" BoundsCheck="true" RuntimeLibrary="rtMultiThreadedDebug"/>
                <Tool Name="VFLinkerTool" OutputFile="$(OutDir)\$(ProjectName)_win32d.exe" LinkIncremental="linkIncrementalNo" SuppressStartupBanner="true" GenerateDebugInformation="true" SubSystem="subSystemConsole"/>
                <Tool Name="VFResourceCompilerTool"/>
                <Tool Name="VFMidlTool" SuppressStartupBanner="true"/>
                <Tool Name="VFCustomBuildTool"/>
                <Tool Name="VFPreLinkEventTool"/>
                <Tool Name="VFPreBuildEventTool" CommandLine="SubWCRev .\..\..\..\  .\..\..\version\VersionTemplate.F90 .\..\..\version\Version.F90"/>
                <Tool Name="VFPostBuildEventTool"/>
                <Tool Name="VFManifestTool" SuppressStartupBanner="true"/></Configuration>

        <Configuration Name="Release|Win32">
                <Tool Name="VFFortranCompilerTool" AdditionalOptions="/fp:strict" SuppressStartupBanner="true" Preprocess="preprocessYes" EnableRecursion="true" FloatingPointModel="source"/>
                <Tool Name="VFLinkerTool" OutputFile="$(OutDir)\$(ProjectName)_win32.exe" LinkIncremental="linkIncrementalNo" SuppressStartupBanner="true" SubSystem="subSystemConsole"/>
                <Tool Name="VFResourceCompilerTool"/>
                <Tool Name="VFMidlTool" SuppressStartupBanner="true"/>
                <Tool Name="VFCustomBuildTool"/>
                <Tool Name="VFPreLinkEventTool"/>
                <Tool Name="VFPreBuildEventTool" CommandLine="SubWCRev .\..\..\..\  .\..\..\version\VersionTemplate.F90 .\..\..\version\Version.F90"/>
                <Tool Name="VFPostBuildEventTool"/>
                <Tool Name="VFManifestTool" SuppressStartupBanner="true"/></Configuration>

        <Configuration Name="Debug|x64">
                <Tool Name="VFFortranCompilerTool" AdditionalOptions="/Z7 /fp:strict" SuppressStartupBanner="true" DebugInformationFormat="debugEnabled" Preprocess="preprocessYes" EnableRecursion="true" WarnInterfaces="true" Traceback="true" BoundsCheck="true" RuntimeLibrary="rtMultiThreadedDebug"/>
                <Tool Name="VFLinkerTool" OutputFile="$(OutDir)\$(ProjectName)_x64d.exe" LinkIncremental="linkIncrementalNo" SuppressStartupBanner="true" GenerateDebugInformation="true" SubSystem="subSystemConsole"/>
                <Tool Name="VFResourceCompilerTool"/>
                <Tool Name="VFMidlTool" SuppressStartupBanner="true" TargetEnvironment="midlTargetAMD64"/>
                <Tool Name="VFCustomBuildTool"/>
                <Tool Name="VFPreLinkEventTool"/>
                <Tool Name="VFPreBuildEventTool" CommandLine="SubWCRev .\..\..\..\  .\..\..\version\VersionTemplate.F90 .\..\..\version\Version.F90"/>
                <Tool Name="VFPostBuildEventTool"/>
                <Tool Name="VFManifestTool" SuppressStartupBanner="true"/></Configuration>

        <Configuration Name="Release|x64">
                <Tool Name="VFFortranCompilerTool" AdditionalOptions="/fp:strict" SuppressStartupBanner="true" Preprocess="preprocessYes" EnableRecursion="true" FloatingPointModel="source"/>
                <Tool Name="VFLinkerTool" OutputFile="$(OutDir)\$(ProjectName)_x64.exe" LinkIncremental="linkIncrementalNo" SuppressStartupBanner="true" SubSystem="subSystemConsole"/>
                <Tool Name="VFResourceCompilerTool"/>
                <Tool Name="VFMidlTool" SuppressStartupBanner="true" TargetEnvironment="midlTargetAMD64"/>
                <Tool Name="VFCustomBuildTool"/>
                <Tool Name="VFPreLinkEventTool"/>
                <Tool Name="VFPreBuildEventTool" CommandLine="SubWCRev .\..\..\..\  .\..\..\version\VersionTemplate.F90 .\..\..\version\Version.F90"/>
                <Tool Name="VFPostBuildEventTool"/>
                <Tool Name="VFManifestTool" SuppressStartupBanner="true"/></Configuration></Configurations>

Thanks and regards,

Daniel

[onkelhotte]

An access violation can have many reasons.

- Do you use Win32 methods?
- Is it a QuickWin program?
- Do you use multithreading by creating threads?

Markus

[danielsue]

onkelhotte wrote:

An access violation can have many reasons.

- Do you use Win32 methods?
- Is it a QuickWin program?
- Do you use multithreading by creating threads?

Markus

Hi Markus,

Thanks for the quick response.This is a console program use multithreaded library, no quickwin or win32 method. The fact is that the program runs well for most of my cases (numerical simulation).

I wonder if the compilation option "/fp:strict" cause this problem. If I delete this option and use the default setting, there will be no accession violation, but the program may crash (iteration failed) for this case.

I will make further test on this compilation option.

Thanks,

Daniel

[SergeyKostrov]

>>I wonder if the compilation option "/fp:strict" cause this problem. If I delete this option and use the default setting, there >>will be no accession violation, but the program may crash (iteration failed) for this case. You've posted Project Configuration options and it would be nice to see codes ( a reproducer? ). Could you post a complete error text, or a screenshot?

[Bernard]

Post VS debugger output?

[danielsue]

Sergey Kostrov wrote:

>>I wonder if the compilation option "/fp:strict" cause this problem. If I delete this option and use the default setting, there
>>will be no accession violation, but the program may crash (iteration failed) for this case.

You've posted Project Configuration options and it would be nice to see codes ( a reproducer? ).

Could you post a complete error text, or a screenshot?

Here is the error information, it crashes after two steps for the test case. I am afraid I cannot put the codes as it is very large and I am not sure at present which part failed.

 enter timeloop
 ------------------------------------------------------------------------
 timestep:     1  time: 1.000E-10 year   delt: 1.000E-10 year   iter:  1   max.sia: 0.000E+00   tol.sia: 0.000E+00
 timestep:     2  time: 3.160E-10 year   delt: 2.160E-10 year   iter:  1   max.sia: 0.000E+00   tol.sia: 0.000E+00
forrtl: severe (157): Program Exception - access violation
Image              PC        Routine            Line        Source
ReactTrans_win32.  01530204  Unknown               Unknown  Unknown
ReactTrans_win32.  01452530  Unknown               Unknown  Unknown
ReactTrans_win32.  0140E572  Unknown               Unknown  Unknown
ReactTrans_win32.  0152FC9D  Unknown               Unknown  Unknown
ReactTrans_win32.  01618493  Unknown               Unknown  Unknown
ReactTrans_win32.  01601915  Unknown               Unknown  Unknown
kernel32.dll       756233AA  Unknown               Unknown  Unknown
ntdll.dll          77339EF2  Unknown               Unknown  Unknown
ntdll.dll          77339EC5  Unknown               Unknown  Unknown

Thanks,

Daniel

[Bernard]

>>>An access violation can have many reasons.>>>

On lowest level it is related to pointer dereferencing.

[SergeyKostrov]

>>...Here is the error information, it crashes after two steps for the test case... What these steps are? The problem is still fuzzy and you need to provide more technical details. Generic explanations are not helping to understand what is wrong, or what could be possibly wrong.

[danielsue]

These steps are timestep in solving reactive transport problem. This case is the only one that have this problem, for the other cases, the program runs normally. The problem may be caused by the level of accuracy. If I do not add compilation option '/fp:strict', the program will fail in newton iteration. After add this option, the program works well if build in win32-debug, x64-debug, x64-release, but causes access violation in win32-release. This seems so tricky to me and it cannot be debugged, as it runs well in debug mode.

Sergey Kostrov wrote:

>>...Here is the error information, it crashes after two steps for the test case...

What these steps are?

The problem is still fuzzy and you need to provide more technical details. Generic explanations are not helping to understand what is wrong, or what could be possibly wrong.

[Bernard]

Daniel,

stack trace is not complete.Can you locate faulting ip?

[Steven_L_Intel1]

Enable the Traceback option in your Win32 Release configuration. You can also try modifying the Debug configuration and setting the optimization level to "Fast" (/O2). You may also need to turn off some of the run-time checking options to more closely approximate a release configuration.

[danielsue]

Steve Lionel (Intel) wrote:

Enable the Traceback option in your Win32 Release configuration. You can also try modifying the Debug configuration and setting the optimization level to "Fast" (/O2). You may also need to turn off some of the run-time checking options to more closely approximate a release configuration.

Hi Steve,

Thanks so much.

Following you suggestion, the bug was detected. The access violation was caused by a subroutine with optional parameters. The subroutine was called by another subroutine use external statement before. After adding explict interface for this subroutine instead of external statement, it works well for all the platform (debug, release, win32 and x64).

Many thanks to all the guys.

Danyang

[Steven_L_Intel1]

If you had Generated Interface Checking enabled, it should have caught this, though it may not depending on compile order.

[Bernard]

danielsue wrote:

Quote:

Steve Lionel (Intel)wrote:

Enable the Traceback option in your Win32 Release configuration. You can also try modifying the Debug configuration and setting the optimization level to "Fast" (/O2). You may also need to turn off some of the run-time checking options to more closely approximate a release configuration.

Hi Steve,

Thanks so much.

Following you suggestion, the bug was detected. The access violation was caused by a subroutine with optional parameters. The subroutine was called by another subroutine use external statement before. After adding explict interface for this subroutine instead of external statement, it works well for all the platform (debug, release, win32 and x64).

Many thanks to all the guys.

Danyang

Typical error pattern when during call chain some junk is left on the stack and  in later stage it used to calculate memory address.