Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

What are reasons for access violation?

Mike_Z_
Novice
3,099 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
Honored Contributor III
3,099 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

0 Kudos
Mike_Z_
Novice
3,099 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?

 

0 Kudos
gib
New Contributor II
3,099 Views

Have you turned on Fortran run-time checking?

0 Kudos
Mike_Z_
Novice
3,099 Views

gib wrote:

Have you turned on Fortran run-time checking?

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

0 Kudos
Steve_Lionel
Honored Contributor III
3,099 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)?

0 Kudos
Mike_Z_
Novice
3,099 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?

0 Kudos
gib
New Contributor II
3,099 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.

0 Kudos
Mike_Z_
Novice
3,099 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.

0 Kudos
Steve_Lionel
Honored Contributor III
3,099 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.

0 Kudos
Mike_Z_
Novice
3,099 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?

0 Kudos
Steve_Lionel
Honored Contributor III
3,099 Views

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

0 Kudos
Mike_Z_
Novice
3,099 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!

0 Kudos
Reply