- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
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
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you so much, this really served me.
Felipe Marchant J.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page