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 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
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
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.
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.
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
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.
