Overwriting memory?

[Kipling__Michael]

Hi All,

I have a program with CPP calling C & FORTAN, C calling FORTRAN & Fortran calling C. It's a very large program developed with VS2005 & IVF 11 on a 32 bit machine.

My IT department decided that I should be upgraded to a 64 bit machine.

I've finally gotten the program to build, but when I run it crashes the second time a FORTRAN routine is called (the routine is called twice in a loop from C).

It crashes the first time a local character variable is initialized with a "Unhandled Exception : Access violation writing location 0x00000000."

I'm guessing that memory has been overwritten somewhere, and I'm guessing I'll have to move line by line to try to find it. However, I'm just not sure I'll recognize it when I see it, since it will not fail there.

Any suggestions?

Mike

[TimP]

I suppose you would start by checking that your old build will run on the new machine, then by checking whether you can rebuild it successfully in 32-bit mode, then maybe using some of the correctness checking facilities. You certainly will need to know whether you are running a 32- or 64-bit Windows, and how to choose the 32- or 64-bit compilers, which must all be consistent.

[Kipling__Michael]

Tim,

The old build runs fine on the new machine. I am building for a 32 bit platform, not x64. I have 2 other fellow developers working on 32 bit machines using the same code who can build & run fine. I am able to build the application andenter data on the GUI. However, during the calculation process the first Fortran routine called fails as I had described.

What are the correctness checking facilities you mentioned.

Mike

[Kipling__Michael]

PS.

I created a simple project with a C++ gui calling a C routine which called the same Fortran routine which is failing in the large project. It worked fine in this test environment.

In my first attempts to run the program, it was failing in another Fortran routine also when the routine tried to modify a character variable. When Icommented the call to this routine, it failed in the next call to a Fortran routine which I described in my first post.

Mike

[Kipling__Michael]

Tim,

In an early attempt to isolate the problem, I had set Fortran/Floating Property/Check Floating-Point Stack to Yes (/Qfp-stack-check). When I set the property to No, the program calculation will now complete successfully.

However, when I try to view the results which calls another Fortran routine, I get the following error:
forrtl: sever (408): fort: (18): Dummy chqaracter variable 'DP_FLAG' has a length 1 which is greater then actual length -1914620250

The value of DP_FLAG is 'D' in the debugger before executing this line of code
IF (DP_FLAG .EQ. 'P') THEN

Executing this line results in the error message.

This is the same type of error message I got earlier when calling theFortran routines which I currently have commented out.


Mike

[jimdempseyatthecove · Accepted solution]

Mike,

Have you tried /gen-interfaces /warn-interfaces (check switch syntax).

I suspect the calling arguments are not correct in places. You can turn these options off after running the check.

It wouldn't hurt to add the subscript out of bounds and uninitialized variables test options as well. This may shake out latent bugs that have been laying around for years without exhibiting problems.

Jim Dempsey

[mriedman]

Indeed bounds checking can expose lots of latent issues.

However the compiler can only check bounds if it knows the array size. Old style codes oftendeclare array arguments with a wildcard size (*). Bounds checking won't work with those.

[anthonyrichards]

If you are passing character strings to Fortran via C, what calling interface are you using?
Do you pass the length as a 'hidden' argument?
Have you sized all address references to 64 bits?
Is the 'hidden argument' now a 64 bit integer? Do your interfaces reflect this?

[mecej4]

The error message Dummy character variable 'DP_FLAG' has a length 1 which is greater then actual length -1914620250 may have been caused by calling from C or another language a Fortran subroutine or function with a character type argument and failing to pass the length of the string as an extra argument.

For the case of character variables of length 1, and with a compiler convention of passing all extra string length arguments at the end after all the normal arguments, such calls will work correctly when argument checking is not requested. When, however, checks are enabled, the declared string length (1) is compared against the contents of the memory location where the hidden length argument should have been present. Since the hidden argument was not passed, the value read from that memory location is garbage; that explains how the string length is seen as negative.

[Kipling__Michael]

Jim,

I was not aware of the /warn:interfaces diagnostic. It did turn up a lot of errors which I'l have to check out.

I have always set the check array & string bounds to Yes.

There are 578 Fortran routines in this program. The analysis code is Fortran 90/95 compatible, but much of the other code (about 1/2) is of the Fortran 77 generation with character lengths defined with (*).

To reply to another of the responses, I've attached a text file withthe cheat notes I assembled while working on this program that covers calling conventions used between the different languages. I hope it is useful to someone.

The program Fortran code and the C code is built into seperate DLL's which the C++ code calls.

Mike

[Kipling__Michael]

Jim,

Thanks a bunch.

The /warn:interfaces diagnostic uncovered quite a few instances where arrays were being passed with different array lengths or character variables with differing lengths.

The program now runs successfully.

Mike

[jimdempseyatthecove]

That is great news Mike. I am glad I was able to help you out.

Keep in mind that a successful run is not proof positive of an error free program.
Not all uninitialized variables checks will catch all uninitialized variables (e.g. in allocated data or data passed in from your C/C++ side).

At least you are further along in the conversion.

Jim Dempsey

[Kipling__Michael]

I have updated the Call_Syntax.txt file to add the line !DEC$ ATTRIBUTES REFERENCE :: to Fortran routines called by C or C++.

Mike