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

Access Violation

Felipe_Marchant
Beginner
2,728 Views
Hi,

I had some problem with my code, and really i don't find the error. The part of code is as follows:

subroutine clouds_data(file, ilong, nnod, npuntos, cl_conect, tnube)
implicit none
character(len = 200) file
integer i, j, ilong, nnod, tnube
integer npuntos(nnod)
integer cl_conect(tnube, nnod)
open(2, file = file(1:ilong)//'.cld', status = 'old')
do i = 1, nnod
read(2, *) npuntos(i), ( cl_conect(j, i), j = 1, npuntos(i) )
enddo
close(2)
end subroutine
That is the subroutine, and when i debug this, the problem is find in the read(2, *) in some iteration depend of nnod (number of nodes). The error is an Access Violation. I increased the stack reserve to 1000000000, but the error continues. The error shown is:

Unhandled exception at 0x00464cd9 in M_P_F_3_D_V15.exe: 0xC0000005: Access violation reading location 0xcdcdcea1.
First-chance exception at 0x00464cd9 in M_P_F_3_D_V15.exe: 0xC0000005: Access violation reading location 0xcdcdcea1.
First-chance exception at 0x00506bb5 in M_P_F_3_D_V15.exe: 0xC0000091: Floating-point overflow.
First-chance exception at 0x77bbb3d3 in M_P_F_3_D_V15.exe: 0xC0000005: Access violation reading location 0x000000bf.
Unhandled exception at 0x00464cd9 in M_P_F_3_D_V15.exe: 0xC0000005: Access violation reading location 0xcdcdcea1.
Thanks for your times.
Best Regards & Happy New Year!
Felipe.
0 Kudos
1 Solution
jimdempseyatthecove
Honored Contributor III
2,728 Views
>>Ok, well ... In this case i work in 64-bit, 1GB in the Stack Size, Could there be problems?.

Not in general.

However, you are observing access to 0xcdcdcd... which smells like uninitialized variables (in this case it is the location of the reference passed to your subroutine that failed).

Steps to resolve:

1) Enable the IVF gen-interfaces and warn-interfaces and compile the code. This compilation will (may) find most of the errors in argument passing forsubroutines and functions. You can turn these options off after this initial tese (and correcting the errors).

2) Compile with IVF runtime checks for use of uninitialized variables. When this does not identify the problem...

3) Then insert diagnostic code early in your subroutine to verify arguments. Test for LOC(arg) being NULL and 0xcdcdcd... and additionally dereference the argument. Either your NULL/0xcdcd... will trigger or the dereference will cause the Access Violation. However, the Access Violation will be reported on the single statement dereferencing the errant argument.

Jim Dempsey

View solution in original post

0 Kudos
6 Replies
mecej4
Honored Contributor III
2,728 Views
You have shown too little to enable one to guess what the cause of the problem is: we do not know the values of the arguments passed to the subroutine, in particular their declared dimensions; we do no know what the contents of the data file are.

The original cause of a runtime error is often quite removed from the error location reported by the compiler runtime. Had it been otherwise, you would probably have removed the error instead of coming here with your questions.

If one of the values read from the data into npuntos(i) exceeds nnod, assuming that nnod is the true extent of the second dimension of cl_connect, that would quite likely cause an access vioation.
0 Kudos
jimdempseyatthecove
Honored Contributor III
2,728 Views
>>Access violation reading location 0xcdcdcea1

Uninitialized data in Debug build on Windows is typically filled in with 0xcdcdcdcd for 32-bit, 0xcdcdcdcdcdcdcdcd for 64-bit. This looks like one or more of your references (file, ilong, nnod, npuntos, cl_conect, tnube) are uninitialized.

Also, a stack size of 1GB will likely have problems on a 32-bit platform.

Jim Dempsey
0 Kudos
Felipe_Marchant
Beginner
2,728 Views
Thanks for your responses.
Ok, well ... In this case i work in 64-bit, 1GB in the Stack Size, Could there be problems?. When i debug my code i can see with Quickwatch,whichat firstreadcyclewithout majorproblems,but at somepointhave problems readingthefile.Tochangeentriesthe error occurred,butindifferenttimes:in a case such asoccursinreadingnpuntos,andanotherincl_conect.
Sorry for my basic question, thanks for your time.
Regards,
Felipe.
0 Kudos
mecej4
Honored Contributor III
2,728 Views
I think that writing a program with statements such as

read(2, *) npuntos(i), ( cl_conect(j, i), j = 1, npuntos(i) ),

which allow arbitrary data to be input into arbitrary addresses, is asking for trouble.

One has to do one of two things to avoid improper memory accesses:

(a) be absolutely sure that no input data will cause data to be entered into an array beyond its bounds;

(b) check that the index is within bounds before allowing input into the array location with that index.

Jim Dempsey has given you a valuable hint as to the origins of your error. I think you would profit by following that lead.
0 Kudos
jimdempseyatthecove
Honored Contributor III
2,729 Views
>>Ok, well ... In this case i work in 64-bit, 1GB in the Stack Size, Could there be problems?.

Not in general.

However, you are observing access to 0xcdcdcd... which smells like uninitialized variables (in this case it is the location of the reference passed to your subroutine that failed).

Steps to resolve:

1) Enable the IVF gen-interfaces and warn-interfaces and compile the code. This compilation will (may) find most of the errors in argument passing forsubroutines and functions. You can turn these options off after this initial tese (and correcting the errors).

2) Compile with IVF runtime checks for use of uninitialized variables. When this does not identify the problem...

3) Then insert diagnostic code early in your subroutine to verify arguments. Test for LOC(arg) being NULL and 0xcdcdcd... and additionally dereference the argument. Either your NULL/0xcdcd... will trigger or the dereference will cause the Access Violation. However, the Access Violation will be reported on the single statement dereferencing the errant argument.

Jim Dempsey
0 Kudos
Felipe_Marchant
Beginner
2,728 Views
Thank you so much, this really served me.

Felipe Marchant J.
0 Kudos
Reply