Internal WRITE causes access violation in Fortran DLL called from Windows App

[sculy]

Greetings! I'm having a problem with VF10.1, and I'm wondering if it's a known issue. We have a Microsoft Windows app (written in C++ and MFC) that loads Fortran DLLs (written in VF10.1). The DLLs are loaded dynamically, executed, and unloaded, all with no errors. However, shortly after the DLL unloads, the MFC app crashes with an access violation.

How do I know that it's a VF problem? The issue can be traced to a solitary internal WRITE statement:

subroutine fcn1(ncmd, nstate, dinputs, doutputs)

!DEC$ ATTRIBUTES dllexport,c :: fcn1
!DEC$ ATTRIBUTES value :: ncmd
!DEC$ ATTRIBUTES reference :: nstate
!DEC$ ATTRIBUTES reference :: dinputs
!DEC$ ATTRIBUTES reference :: doutputs

integer(4) ncmd, nstate
real(8) dinputs(*), doutputs(*)

CHARACTER(LEN = 80) :: errname

! The following line causes an access violation sometime after this DLL is unloaded.
! If the line is commented out, the access violation does not happen.
WRITE(errname,'(a,i1,a,i1)')'MkTable_LA-err-',dinputs(1),'-',dinputs(2)

...

end subroutine fcn1

If the WRITE statement is commented out, the access violation goes away! In this test example, the variable "errname" is not used anywhere else, and does not programmatically affect the results passed back to the Windows app in any other way.

This only appears to be an issue in MFC, and only for DLLs built with Visual Fortran. I can provide a Visual Studio 2005 solution with a simple test that demonstrates this to anyone who is interested. I'm also posting an issue to Intel support, but I thought I would check here as well.

Thanks!
Steve Culy
sculy@goldsim.com
GoldSim Technology Group
www.goldsim.com

[Steven_L_Intel1]

What happens if you change the WRITE to a file write (specify a unit number)? Or change it to something like:

if (ncmd=99999) WRITE...

where 99999 is a value ncmd will never have? I haven't seen your issue show up in our support system yet.

Also, what have you specified for the run-time library type? (Fortran > Libraries > Use Run-time library)? Try "Multithreaded DLL" (not a Debug variant.

[sculy]

Writing to a file does not cause the access violation; it only happens when the unit is a character variable.

Also, the statement has to be executed for the access violation to occur. Inserting the "IF (ncmd .eq. 99999)" does not cause the access violation.

The access violation only happens when linking statically (Multithreaded option for run-time libraries). It does not happen when linking as Multithreaded DLL. So that means we have a work-around, although we would like to see this fixed for the static case.

The support issue has now been logged as issue 478901 (Steve, you were just too speedy!), and my test VS 2005 solution should be included. If anyone who doesn't have access to the support system wants the solution, let me know, and I'll email it to you.

Thanks for the quick response,
Steve C.

[Steven_L_Intel1]

Ok, we'll continue this through support for now and report back here when we have an answer.

It may not be possible to fix it for static linking, but we'll see...

[jarvusluntatintel]

I got this same behavior calling my Intel 9.xFortran dll froma C# exe. I was converting numbers to a string, something like:

write (astring, '(g10.2)') inumber

I eventually commented those write lines out.