Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26729 Discussions

What are reasons for access violation?

Mike_Z_
Novice
538 Views

In operator containing one reference to array element I have message:

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

That element could not be a reason - I check it. What are another possible reasons?

0 Kudos
13 Replies
jimdempseyatthecove
Black Belt
538 Views

The typical cause is accessing an undefined variable reference .OR. indexing out of bounds.

This error is a result of accessing data at a virtual address that is not (or will not) be mapped to the process.

Potential causes:

A subroutine/function requiring N arguments but the caller passes in some number less than N arguments.
(Enable the compile time diagnostics to warn on interface mis-match).

An access to an array with an index that is so far out of range that it attempts to access data at a virtual address that is not (or will not) be mapped to the process.
(Enable runtime diagnostics to check for array indexing issues)

Use of an uninitialized pointer.

Jim Dempsey

Steve_Lionel
Black Belt Retired Employee
538 Views
Mike_Z_
Novice
538 Views

Thanks, checked all, nothing found. But when I generate code for x64, I have access violation error. After regenerating code for x32 at the same place whith same data I have:

forrtl: error (65): floating invalid

/fpe0 option is ON

What can I to do?

 

gib
New Contributor II
538 Views

Have you turned on Fortran run-time checking?

Mike_Z_
Novice
538 Views

gib wrote:

Have you turned on Fortran run-time checking?

Yes, of course. All, but silence...

Steve_Lionel
Black Belt Retired Employee
538 Views

You have data corruption going on somewhere. It can be hard to diagnose. What I sometimes did was start commenting out code before the error until I found the behavior changing. Have you enabled /warn:interface (Check Routine Interfaces)?

Mike_Z_
Novice
538 Views

Steve Lionel (Ret.) (Blackbelt) wrote:

You have data corruption going on somewhere. It can be hard to diagnose. What I sometimes did was start commenting out code before the error until I found the behavior changing. Have you enabled /warn:interface (Check Routine Interfaces)?

Commenting is a good idea, program is not so big. I'll try it, thanks. I printed all variables included in problem operator - nothing found.

Yes, I set /warn:all

I need comment code from error to top, or vice versa?

gib
New Contributor II
538 Views

"I need comment code from error to top, or vice versa?"

I'd start from the place where the crash occurs, and work backwards.

Mike_Z_
Novice
538 Views

Commenting code to top gives different results: sometimes same error ((65): floating invalid) at same operator, sometimes (65): floating invalid in another operator; sometimes severe (182): floating invalid - possible uninitialized real/complex variable in another operator. So, for now I have no idea.

Steve_Lionel
Black Belt Retired Employee
538 Views

That should result in a very small reproducer, yes? Look at the code that is left and try to figure out what you did wrong. I assume this is a debug build.

Mike_Z_
Novice
538 Views

More accurate commenting gave the following:
error arise in operator
d = sqrt(rhos2+rhsg*(rhsg-2.0d0*rhos*(st*sin(tg)*cos(phs-psg(j))+ct*cos(tg))) (*)

for Debug x32 commenting to top gave small change in the next preceding operator:
from error (65): floating invalid
to error (182): floating invalid - possible uninitialized real/complex variable.
Than behavior is not changed until beginning of program, so I can suspect (*)
operator. I decomposed it to
stg = sin(tg)
ctg = cos(tg)
cpsg = cos(phs-pg)
d = st*stg*cos(phs-pg)+ct*ctg
d = sqrt(rhos2+rhsg*(rhsg-2.0d0*rhos*d) (**
)

but error (65): floating invalid still points to last operator (**)
Behavior in Debug x64 is very similar:
error severe (157): Program Exception - access violation
and commenting do not chage it.

Funny, but when I wrote it, I find error!
Sometimes I tried compute real d as sqrt from negative number!
I really sorry for my stupidity, and a lot of thanks to all!

At the same time strange why so obvious error wasn't detected neither the compiler nor the runtime?

Steve_Lionel
Black Belt Retired Employee
538 Views

The Floating Invalid is the correct response to SQRT of a negative number. But this isn't the cause of an access violation.

Mike_Z_
Novice
538 Views

Since I mostly work in a 64 bit environment, it confused me. But it was unforgivable to miss SQRT when I switched to 32 bits and saw Floating Invalid... Anyway, error was corrected. Thanks again!

Reply