Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29282 Discussions

forrtl: severe (157): Program Exception - access violation

msaadatpour
Beginner
‎02-10-2011 06:33 AM
830 Views
I've added a main procedure to the source code of progam to run the software more and more. In Debug mode the program is excuted and I would be able to run the program. But when I change the running mode to "release", the program would be compiled successfully but when I debug the program there are the message "Unhandled exception at 0x0056da02 in HydrodynaicCali.exe: 0xC0000005: Access violation reading location 0xffffffff" and/ or "forrtl: severe (157): Program Exception - access violation". I've changed some project properties for example Floating Point and Diagnosis, but there were no changes. What should do I? This problem is due to software or hardwareinconsistency?


All the Bests
M. Saadatpour
0 Kudos

Link Copied

1 Reply
mecej4
Honored Contributor III
‎02-10-2011 06:56 AM
830 Views
A number of different types of programming errors can result in a crash reported as an access violation. More infrequently, compiler bugs can also cause the same symptom.

The program reported the IP (instruction pointer) value (0x0056da02) at the point where the access violation occurred. You can consult the link map, if one was generated, or using Dumpbin.exe on the program, if no map was generated, to locate the function in which the crash occurred.

You may also try recompiling with the same options as in the "release" mode, but with traceback enabled. Be prepared, however, for the error to go underground or appear somewhere else when compiler options are changed.

Bugs that cause program crashes are more "user friendly" than bugs that skew the program output so slightly as to make the results appear reasonable, hard as it may be to accept this property of programs!
0 Kudos
Copy link
Reply

Community support is provided Monday to Friday. Other contact methods are available here.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

For more complete information about compiler optimizations, see our Optimization Notice.