run time errors on other computers

[tsimm3]

I build a DLL to be used by our customers. When I build it with IVF 9.1 it works correctly. When I build it with IVF 11.1 it works on my computer but not on other computers. I assume that I need to link something into the DLL that I didn't need to link in before. Without knowing the details of my program or the run time errors, can you suggest anything?

[Steven_L_Intel1]

If you're not going to even tell us what the errors are, that makes things difficult. Usually the problem people have with running DLLs on other systems is not having the dependent DLLs there. Read this article for more information. You may also need to install an appropriate Microsoft Visual C++ redistributable package. If your DLL is not being called by Fortran, you can build it with the "Multithreaded" libraries instead of "Multithreaded DLL", to eliminate dependencies on other DLLs.

[tsimm3]

I haven't seen the error messages myself, but a user reported "forrtl:severe(40):recursive I/O operation".

[TimP]

recursive I/O error doesn't appear likely to be associated with missing libraries. It's due to invoking a READ or WRITE inside a WRITE, such as when a function call inside a WRITE tries to WRITE (possibly in an attempt to put out its own error message).

[tsimm3]

The confusing thing to me is that the same source code, when compiled with 9.1, works on my computer and on other computers, but when compiled with 11.1 works on my computer but not on other computers. It seems that my computer has something the other computers don't have, and it seems that it would be related to the fact that I have 11.1 installed and the others don't.

[Steven_L_Intel1]

I can't imagine what might make this behavior different depending on installed compiler version. Does your DLL link to the DLL libraries? Is it called from Fortran or from some other language?

[tsimm3]

I assume that the other computers don't have any compiler installed. I normally compile with the "Multithreaded" option, but I have also tried the "Multithread DLL" option for the Runtime library. In the latter case I supplied the redistributable DLLs that it needed, which were libifcoremd.dll, libifportmd.dll and libmmd.dll. My dll is called by a C++ application. I wish I could give you more information, but it's a large application that has been under development for over 30 years by various developers on government contracts. When I upgraded from 9.1 to 11.1 I converted the project and used the same source code.

[Steven_L_Intel1]

If you can't reproduce it but others can, for the same DLL, that rules out a lot of things. As was said above, the Fortran I/O system thinks you are starting a read or write on a unit where another read or write is already in progress. This usually happens if you do something like:

WRITE (9,*) F(X)

where function F also does a WRITE to unit 9. So examine your code to see if something like this might happen.

[mecej4]

Sometimes, an error such as an array overrun or using an uninitialized variable can go undetected for a long time, only to rear its head when a new compiler, new OS or different compiler switches are used. It may also happen that there is a delay between the error happening and the Fortran runtime catching something noticeably wrong. Tracing the error back to its source can be quite difficult.

A ray of hope: if your DLL is moderate in size, whereas the C++ application is huge, you could intercept the call to the DLL that is about to cause a crash, record the arguments (and global variables, if any) and build a small test application that does nothing more than calling the DLL with the same arguments and environment.

[tsimm3]

Thanks for the suggestions. The part that doesn't make sense to me is why I don't experience the run time errors when I run the software on my computer and other users do, using the same inputs. I can't debug the problem when it doesn't occur on my computer. I'm sure we don't do any recursive I/O. Fortunately we can go back to IVF 9.1 and avoid the problem. If I figure it out I'll let you know. Thanks again.

[Steven_L_Intel1]

You might have a memory corrupter somewhere in your code. I sympathize as this sort of thing can be very difficult to track down, especially if it doesn't break for you.

[tsimm3]

Here is the essence of code that works on my development computer but will not work on some other computers when I compile with IVF 11.1:

REAL*8 ZVDIST(:)

ALLOCATABLE ZVDIST

ALLOCATE(ZVDIST(1000), STAT=STATUS)

IF(STATUS .EQ. 0) THEN

DO I = 1, 1000

ZVDIST(I) = 0.0

ENDDO

ENDIF

This code is in a DLL that is loaded by a C++ application. When execution reaches the first assignment statement the DLL is unloaded with no explanation. The problem does not occur when I compile with IVF 9.1. Is there a more reliable or better way to initialize an allocated REAL*8 array?

[Steven_L_Intel1]

What processor model does the "other computer" have? If you compile with 11.1 then a processor that supports Intel SSE2 instructions (Intel Pentium 4 and compatible CPUs from other manufacturers) is required. I could imagine that this loop is vectorized using SSE2 instructions, and if you ran on a VERY old computer that didn't support SSE2 then the program would just die.

Try building with the /arch:ia32 option (in Visual Studio, this is Code Generation > Enable Enhanced Instruction Set > No Enhanced Instruction Sets.

I would also recommend, as a matter of style, to replace the loop with:

ZVDIST = 0.0

This should not make a difference for the problem you describe.