- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Post VS debugger output?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>An access violation can have many reasons.>>>
On lowest level it is related to pointer dereferencing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Daniel,
stack trace is not complete.Can you locate faulting ip?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you had Generated Interface Checking enabled, it should have caught this, though it may not depending on compile order.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page