topic Re: forrtl: severe (157): Program Exception - access violation in Intel® Fortran Compiler

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

mankoff — Thu, 14 Aug 2008 17:02:00 GMT

Dear Fortran Forum,

I'm getting the following error:

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

I've spent some time looking for a solution and it seems like this message means I'm reading outside an array or something similar.

But I'm hesitant to change the code, as it compiles as-is under a bunch of other compilers (ifort on Mac OS X, plus Absoft (9.2 OS X; 8.2 Win) and GNU gfortran on OS X).

So I think it is probably some compile options. I've tried to take the ifort OS X compile options and replicate on Windows, but I still get this 157 error.

Should I post my build.bat file? Can anyone offer any suggestions?

Thanks,

-k.

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

Lorri_M_Intel — Thu, 14 Aug 2008 17:37:42 GMT

There are a number of reasons why you might get this error. Basically it means you're touching memory you're not allowed to.

You could be writing into a constant parameter, you could be reading/writing outside of bounds, you could be accessing an uninitialized variable .... lots of things could cause this.

Your first course of action should be to try running it under the debugger, to see where it's failing so you can get a clue. If it doesn't fail with debug, try setting /traceback. Oh, and even if you don't *want* to change the code, you should check for reading/writing out of bounds by setting /check:bounds.

- Lorri

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

mankoff — Sat, 16 Aug 2008 22:51:02 GMT

Hi Lorri,

/check:bounds gives an error, but one that I would like ignored... If I use /check:bounds this problem comes up, that I just posted about here:

http://software.intel.com/en-us/forums/showthread.php?t=60242#63863

If I remove /check:bounds then the code gets farther, then runs into the 157 error.

Still working on it...

-k.

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

Steven_L_Intel1 — Sat, 16 Aug 2008 23:00:00 GMT

It is unlikely that using a compiler option will fix the problem for you. See this article I wrote on access violation - it may help you.

[Edit - link updated]

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

jimdempseyatthecove — Sat, 16 Aug 2008 23:38:00 GMT

For the source file, compiled with /check:bounds,which generates the error if after walking the code and verifying the bounds violation is permissible (could be a bad assumption on your part) you can compile that source file without the /check:bounds, but leave the option on the other files. Work through this source file at at a time.

Also, look at the address being referenced that produces the access violation.

If the address is in the range of about 0 to 4K, or 0 to 4MB on x64 platform, then there is a high probability you are attempting to reference a deallocated array or dereference a NULL pointer to a structure. Looking in the Dissassembly window and viewing registers might confirm this.

If the address is way up high (or negative on Windows system) then suspect that your code stomped on an array descriptor .OR. you are running multi-threaded and your code is creating a local (e.g. automatic) then passing the array descriptor to a different thread and exiting the subroutine prior to the other thread(s) finishing use of the array descriptor.

Just because a program runs without crashing or blatently wrong output does not mean the program is running witout error. And one that could blow-up on you some day.

Jim Dempsey

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

mankoff — Sun, 17 Aug 2008 01:13:39 GMT

Hi Steve, I read your article. I'm still hoping this can be dealt with at the compiler level. I have hope because this code does compile with ifort on Mac OS X Intel and on Windows (with Absoft 8.2 and 9.0) and on Mac OS X PPC (Absoft 9.2) and Mac OS X Intel with gfortran. Given all that, especially the ifort on OS X, I hope ifort on windows can handle it too. -Ken.

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

mankoff — Sun, 17 Aug 2008 01:30:54 GMT

Hi Jim,

Thanks for your suggestions and information.

JimDempseyAtTheCove:

For the source file, compiled with /check:bounds,which generates the error if after walking the code and verifying the bounds violation is permissible (could be a bad assumption on your part) you can compile that source file without the /check:bounds, but leave the option on the other files. Work through this source file at at a time.

I've changed the build script to compile each file to object and then link, so that I can have different options for different files as you suggest.

I'm now stuck where one file stops on an obvious and purposeful out-of-bounds index:



      DO 206 N=1,NM8

  206 KE(N,1)=0.

if /check:bounds is used, and gives the 157 error if it is not used.

JimDempseyAtTheCove:

Also, look at the address being referenced that produces the access violation.

If the address is in the range of about 0 to 4K, or 0 to 4MB on x64 platform, then there is a high probability you are attempting to reference a deallocated array or dereference a NULL pointer to a structure. Looking in the Dissassembly window and viewing registers might confirm this.

If the address is way up high (or negative on Windows system) then suspect that your code stomped on an array descriptor .OR. you are running multi-threaded and your code is creating a local (e.g. automatic) then passing the array descriptor to a different thread and exiting the subroutine prior to the other thread(s) finishing use of the array descriptor.

32 bit platform, non-multi-threaded, error is:



Z:GISSGCMmodelIIifortwin>.mwin.exe

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

Image              PC        Routine            Line        Source

mwin.exe           005BBE19  Unknown               Unknown  Unknown

JimDempseyAtTheCove:

Just because a program runs without crashing or blatently wrong output does not mean the program is running witout error. And one that could blow-up on you some day.

Ah. Yes... this code was originally written so that it intentionally exploited known compiler bugs. Most of those have been ironed out because those compilers don't exist anymore and we've gotten it running on other platforms and compilers, but I can never be totally sure.

It has errors and bugs (as all code does). But at 10k+ lines I'm not worrying about them right now, I'm just trying to get it to compile. Then I'll validate outputs against baseline compiles on other platforms.

Finally, I'm trying to run this in the debugger, but it is less than helpful:



(idb) run

Starting program...

Thread generated exception: Access Violation



(idb) frame

#0 0x005bbe19

(idb) info source

Current source file is unknown

(idb) info line

No so
urce file named.

I'm running it in the directory with all the source and object files. I'm familiar with basic gdb but not with this idb.

Thanks for any more help you might have,

Ken Mankoff

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

TimP — Sun, 17 Aug 2008 06:58:54 GMT

Compile and link with traceback enabled is often helpful on Windows. I don't think there is any effort to facilitate debugging under mwin.
As you appear to have an intentionally intractable source code, you might make the effort to compile and run debug mode (/Zi), both with optimization off (default for /Zi) and on.

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

jimdempseyatthecove — Mon, 18 Aug 2008 20:19:03 GMT

Ken,

As a quick hack to work around the problem insert diagnostic code to find out the largest value of NM8 used on statement

DO 206 N=1,NM8

e.g.

integer, save :: LargestNM8 = 0
...
if(NM8 .gt. LargestNM8) then
LargestNM8 = NM8
write(*,*) NM8
endif
do 206 N=1,NM8
...

When you find the largest value, if that does not shed light on anything, then the hack is to allocate KE(:,:) or declare it, such that it is large enough to accomidate the 0's.

Also, if this introduces other problems in code execution prior to the former bounds error, then this indicates the KE array may by design, overlay something else that needs to be referenced alternately as KE(n,m) and by that something else.

The hunt is on.... good luck.

Jim Dempsey