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

Acess violation reading location 0x00000000 problem - write problem

Yong_Tang
Beginner
748 Views
Hello,

I have a solution which consists of two projects. The main project (console)is written in C and the second project is written in FORTRAN (static library). A problem occurs whenever I use statement write (*,xxx) in the FORTRAN project, which is supposed to output something to the "command terminal". However, it gave me an error like "access violation reading location 0x00000000". I have no idea why this is happening. I am pretty sure the write statement is correctly used. Can anyone help?

Yong
0 Kudos
11 Replies
Steven_L_Intel1
Employee
748 Views
Without seeing the actual code, it's impossible to say. I suggest you read this and see if it gives you any ideas.
0 Kudos
Yong_Tang
Beginner
748 Views

Steve,

Thank you! It's a good article. However, I still have not figure out my problem yet. In addition, I found that some of the common block variables are initialized in the modules (I know it is not a clean way to use common in modules, but it is as it was in the old program). The initialized values can not be seen in the subroutines which include those modules. For example:

moduleA
COMMON/CM/X

CHARACTER*4 X(3)/'EXEC','TITL','CMNT'/

save /CM/

end module A

SUBOUTINE B
use A

xxxx
end subroutine

when I was debugging in Subtoutine B, the values ofX are all empty strings.

Strangely, it was working if the fortran code was a stand-alone executable. Now it is a static library. I wonder whether it has something to do with this.

Any idea?

0 Kudos
Steven_L_Intel1
Employee
748 Views
Why don't you focus on the access violation for now.
0 Kudos
Yong_Tang
Beginner
748 Views
Steve,

You're right. Let's solve one problem at one time. I did a little more test and figured that the "STOP stop-code" gave me the same error message. It leads me to believe that the FORTRAN library codes failed to access the console while trying to output to the console. The C code does output something to the console as well. But I think there should not be conflicts. BTW, I used the "QuickWin" as the runtime library for the FORTRAN project. Would this have some impact?
0 Kudos
Steven_L_Intel1
Employee
748 Views
If you used QuickWin, then there is no console. Fortran output will go to the QuickWin window and C output will go, probably, nowhere. This has no connection with the access violation.

Now that you say you have C code, it is possible that you have corrupted the stack using wrong calling conventions. This can cause bizarre symptoms often much removed from the point of the problem.

What compile options do you use for Fortran and C? (You can get these from the Command Line property pages for each language.) How are the C routines declared in C and in Fortran?
0 Kudos
Yong_Tang
Beginner
748 Views
Sorry for the late reply. The compile options I used are

FORTRAN,

/nologo /debug:full /Od /I".\lib\" /I".\rc\" /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:logicals /fpscomp:general /warn:errors /warn:unused /warn:interfaces /real_size:64 /Qsave /align:rec8byte /align:dcommons /assume:dummy_aliases /Qzero /fpe:0 /Qftz /iface:cvf /module:"Debug\" /object:"Debug\" /FAs /Fa"Debug\" /traceback /check:bounds /check:format /libs:qwin /c

C,

/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MT /Fo"Debug\" /Fd"Debug\vc80.pdb" /W3 /nologo /c /Wp64 /ZI /TP /errorReport:prompt

Hope this helps.
0 Kudos
Steven_L_Intel1
Employee
748 Views
I see you use /iface:cvf which will make all the calls use STDCALL. Have you specified __stdcall on your C routines? How are you dealing with the naming convention differences? If you have inconsistent calling conventions, this will corrupt the stack and cause all sorts of bizarre behavior, including the symptoms you describe.

What happens if you remove /iface:cvf and rebuild?

You have a lot of other Fortran options enabled that are not defaults - do you know what they all do?
0 Kudos
Yong_Tang
Beginner
748 Views
Thanks, Steve. In my c code, I wrote

extern

void B();

And the calling convention I used is "__cdecl (/Gd)".

In my FORTRAN code, I wrote

SUBROUTINE B

() BIND(C,NAME="B")

I will try to remove /iface:cvf and rebuild. I don't know all the FORTRAN options that are being used as they were left from previous FORTRAN project.

() BIND(C,NAME="B")

I will try to remove /iface:cvf and rebuild. I don't know all the FORTRAN options that are being used as they were left from previous FORTRAN project.

() BIND(C,NAME="B")

I will try to remove /iface:cvf and rebuild. I don't know all the FORTRAN options that are being used as they were left from previous FORTRAN project.

0 Kudos
Steven_L_Intel1
Employee
748 Views
I wondered if you had done something like that. Yes, you are corrupting the stack on every call. Remove the /iface:cvf and things will improve a lot.
0 Kudos
Yong_Tang
Beginner
748 Views
By removing it, do you mean tokeep it as default?

I used the "default" and recompiled, it gave me "Error137fatal error LNK1120: 1 unresolved externals" error now.
0 Kudos
Steven_L_Intel1
Employee
748 Views
If you are using Visual Studio, set the property External Procedures > Calling Convention to Default or "Inherit from project defaults". This will remove that option.

What is the complete error message? The message names a routine - is it a C routine or a Fortran routine and how is it declared?
0 Kudos
Reply