Fortran Dll crashed@internal write under IVF8.0 while works under CVF6.x

[wu_internet]

Dear all,

I am porting a compaq fortran project (version 6.x) over to the intel
fortran compiler (version 8.0). However, crash always happens at the
internal write statement under the intel fortran compiler.

=========
project brief:
=========
The soultion comprises two parts, one is the c++ project, which in charge of
the user interface, the other project is a Fortran Dll project. The Fortran
Dll is invoked by the C++ project. the problem I meet here is every simple,
the C++ project is just a framework of the dialog based mfc win32
application. In the code response to the click OK button, it will invoke the
fortran dll. The Fortran dll is built as the name of TestDll.dll. The core
part of the C++ and Fortran code are shown as follows:


=========
C++ code
=========
...
typedef unsigned int (__stdcall *_FPTR_START_APP) ( void * );
...

if (nResponse == IDOK) ////code corresponding to the click OK
button
{

CString fileName = "abc";
m_hSimDLL = LoadLibrary((LPCTSTR)"TestDll");
FARPROC fPtrStartApp = ::GetProcAddress( m_hSimDLL, "StartApp" );

void* pvSecurity = NULL;
unsigned int* puiThrdAddr = NULL;
m_hThread = (HANDLE) _beginthreadex( pvSecurity, 0,
(_FPTR_START_APP)fPtrStartApp, (void *)(LPCTSTR)fileName.GetBuffer(0), 0,
puiThrdAddr );
...//idle or do something here so that the thread of the fortran Dll will
run and can be debugged.
}

=========
Fortran code
=========
Corresponding Fortran Dll is made of by the following code:

! ---------------------------------------------------------------------
Subroutine StartApp(iAddressStrBuf)

!DEC$ ATTRIBUTES DLLEXPORT::StartApp
!DEC$ ATTRIBUTES ALIAS: 'StartApp'::STARTAPP
!DEC$ ATTRIBUTES VALUE::iAddressStrBuf

integer iAddressStrBuf
integer i
character*32 strTest

i=555

write(strTest,'(i10.10)') i
return
end subroutine StartApp
!----------end of the fortran dll project ----------------------------------

=========
Symnpton
=========
Whenever the internal write statement is invoked, the program will crash and
report the error of access violation occurred.

If there is anyone knows the issue, could you please give me a hand.

=========
Attached
=========
It appears that I can not send the whole project sample files in zip format,
I will send to those who responsed to this email either in person or to the
newsgroup if needed.

Best Regards,

David

[Robert_S_6]

David,

I had the same problem with an internal write statement. Use the debug Single threaded runtime library to compile the fortran. The internal write would not work with any other runtime library.

Bob

[Jugoslav_Dujic]

See this thread:

http://softwareforums.intel.com/ids/board/message?board.id=5&message.id=318&highlight=for_rtl_init_#M318

the essence of the problem is that you're linking agains static version of RTL, and the run-time library never gets to know thatanother thread has started, and thus never initializes itself. There's no Fortran equivalent of _beginthread(ex), and _beginthread(ex) does no good as it initializes only C RTL.

As said there, the only workaround appears to be to link with DLL version of RTL (as it's able to catchup by means of handling THREAD_ATTACH in DllEntryPoint.

The problem looks inherited from CVF; however, I'm curious whethera solution/workaround is possible.

Jugoslav

[Jugoslav_Dujic]

Bob, I just tried it with Multithreaded DLL and it works (IVF .044).

It indeed works with Single-threaded Static as well, but I doubt it's thread-safe in such setup.

Jugoslav

[Robert_S_6]

Jugoslav,

Maybe I have something else set up incorrectly then, because the only way my dll will work is with the single threaded run time library. I am now using IVF 4.7, but it ws the same with IVF 4.0 as well.

Bob

[wu_internet]

Many thanks for the help, the dll seems work with the link to the single threaded libraryBut new problems emerge as I have to work around the calling to endthreadex which is not supported in the above library.

David

[Steven_L_Intel1]

My experiments showed that it was only the single-threaded debug DLL library that was incompatible with this combination. Single or multithread non-debug DLL worked.

[Robert_S_6]

Steve,

I am not that familiar with everything that each of these particular libraries do, nor do I pretend to. I am just wondering if there is work being done on the consistancy with which they work? In other words, why is one library compatible and another one is incompatible? I get frustrated when i have to recompile my code until I get the right setup.

Bob

[Steven_L_Intel1]

You have to make sure that all of your application is using a consistent set of libraries, especially where threaded vs. non-threaded is involved., or else strange errors can occur. The case I looked at before involved a Fortran DLL called from a VB.NET application. Apparently that environment requires that one not be using the debug threaded DLL Microsoft libraries, as these are incompatible with the non-debug threaded libraries.

Yes, it would be nice if all the variants would play nice together. Microsoft adds some checking code in their debug libraries that can cause problems when other code loads non-debug libraries. It's not clear that there's anything that we (Intel) can do other than help document the issues.

[Jugoslav_Dujic]

To David:

_endthreadex? I recommend against it. The preferred method toexit a thread is plain RETURN from theentry routine rather than any variety of ExitThread. At least, you can encounter problems if you have local allocatable arrays which are not cleaned up on _endthread(ex).

To Steve:

Which sample did you try? Project in the zip fileposted in this threadcrashes with Static Multithreaded Debug.

I wish you or someone else from Intel could explain the behaviour, and whether it's a bug or a "feature"; My explanation above about initialization is just an assumption.

Jugoslav

[Steven_L_Intel1]

I'll ask our libraries people to look at this. I didn't try this example - I was referring to a separate program sent in by another user.

[wu_internet]

A further question follows on the previous issue, I have been able to sort out all the previous problems by statically link to the single threaded library. However, due to that the exe which calls the fortran Dll has been a version for some time in Customers hand. In order for the compatibility, I can not change the exe version freely. Therefore, I have to work around to find the solution to kill the thread if needed in the Fortran Dll. I think the only possible way is to link to the multi-threaded dll library, however, after link successfully, the exe can not load the library successfully, The pop up windows says "can not load the following dll..., the installation may not be complete, the specified module could not be found" can anyone tell me the reason why such failure happens. It does not matter if I supply the DllEntryPoint or not.

David

[Jugoslav_Dujic]

Probably, you have to redistribute (copy to customer's computer) DFORMD.dll. (Installed to your c:WinntSystem32), which is "Non-debug Dll multi-threaded" library (you're not allowed to redistribute "Debug" ones, such as DFORMDD and DFORRTD).

Let me spare few words about criteria of the run-time libraries to link with.

1) You have to use DLL version of the RTL when any of the following conditions is true:

a) calling .exe and the .dll share I/O unit numbers (e.g. .exe OPENs, .dll READs)

b) .exe ALLOCATEs and .dll DEALLOCATEs the memory (or vice versa)

c) (there are probably few more situations of such kind, buth the two above are most common)

2) You have to use Multi-threaded version of the RTL when all of the following conditions are true

a) your code runs in multiple threads

b) the threads may be ran simultaneously and all of them execute Fortran code (i.e. if GUI is in C++, anda single number-crunching threadis in Fortran, there's no real need for multi-threaded RTL)

or if single-threaded limitations preclude usage of single-threaded RTL (like internal write problem discussed in this thread).

Thread killing (if you mean TerminateThread) is never a good idea. Whatever RTL is under the hood, chances are good that you leave it in a zombiestate. Use whatever synchronization methods which do the job of "cooperation" between the caller and the thread (the simplest being global logical variable, a bit more complex event objects -- CreateEvent & co and critical sections Create/Enter/LeaveCriticalSection, and there are mutexes and semaphores as "heavy artillery"). The idea is that the caller sets the event, and the thread periodically checks whether it should exit gracefully -- see. e.g. ThreadDlg sample on my home page.

Also, have in mind that you have situation 2b), linking against multi-threaded RTL is just a prerequisite -- in addition, you have to ensure that no two threads have conflicting access to any variable (i.e. one reads, the other writes). At least, you have to compile with /recursive or /automatic switch, and ensure that either there's

- no global data (module or common) at all

- if you have to have global data, ensure that they're read-only

- if they're not read-only, ensure that the access is not conflicting (e.g. use critical sections).

Such situations are tricky to get right.

Jugoslav

Message Edited by JugoslavDujic on 04-19-2004 11:50 AM

[wu_internet]

To Bob,

I don't the reasons why it happens, When I install the IVF, the library file, such as libmmd.dll, libifcoremd.dll were not in the windowssystem32 directory, subsequently, I was not able to make this project work when linked to multi-threaded dll library, apart from the same as you, only the statically linked single threaded dll works.

Regards,

David.

[Robert_S_6]

David,

Thanks for the tip. That did the trick. Now my dll's will work with multi-thread dll run-time library.

Bob

[peledrg]

Hi Steve,

My application is crashing in aninternalFORTRAN WRITE statement on XP using the 8.1 compiler in VisualStudio.NET. Any new development since 2004?

Rachel

[Steven_L_Intel1]

Rachel,

I am not aware of any issues with internal WRITE in current compilers and libraries. Which revision of the 8.1 compiler are you using? (8.1.???) Do you have a test case I can look at?

The current version is 9.1.028.

[peledrg]

Steve,

I am using Version 8.1.2380.2003. My application is 250,000 lines long, higly propriatery and I can note create a simple case where it crashes. However, I can make it crash all the time in one of the statments. I have a total of 5500 WRITE statents in the code. Come writing to a UNIT and some are internal WRITE. Even trying to wrap the fortran internal WRITE is a major effort. Any words of wisdom?

Rachel

[Steven_L_Intel1]

8.1.2380.2003 is not the compiler version. That's the VS.NET integration version. The compiler version is in the name of the file you downloaded for installation or you can see it by doing Start..Programs..Intel Software Development Tools..Intel Fortran Compiler 8.1..Build Environment for IA-32 Applications. The version will be in the first line output.

Generally, I would advise trying a current compiler version. You can have 8.1 and 9.1 installed side by side.

[peledrg]

Steve,

I have installed the Version 9.1.3291.2003 and I am getting the crash in the same location in an Internal FORTRAN WRITE stament.

Am I the only person with this problem on XP? XP has been around for almost 5 years. We are only now migrating to this environment.

P.S. I had a problem where NatDbgEE.dll was missing from the Visual Studio .NET 2003 environment. I copied it from a machine that had the 8.1 Compiler. I also had a problem installing 9.1 without deleting 8.1. Therefore, I uninstalled 8.1 from my PC.

Any other ideas?

Thanks,

Rachel

[Steven_L_Intel1]

I doubt the problem has anything to do with XP itself. My guess is a coding error in your application that is memory layout dependent, but without an example it's impossible to say foir sure. I have not seen reports of a problem with internal WRITE in a very long time. That you are having a hard time reproducing it in a smaller sample lends weight to the idea that the problem is in your code somewhere.

Is this reproducible while in the debugger? What virtual address (VA) is shown in the error message? What is the address of the variable into which you are writing?