First-chance exception?

[John4]

Hi,

I've been having trouble compiling some source. The problem is that I get a "First-chance exception" error whenever I try a character assignment where the left side (which is part of a module in a dll) is involved somehow in the right side, say:

!In the dll:
module dll_mod
character(256) :: text
!DEC$ATTRIBUTES DLLEXPORT :: text
end module


!in the main program:
use dll_mod

text = ' whatever'
text = ADJUSTL(text)
write (*,*) text
read(*,'(A)')
end


Since "msvc80d.dll" was involved in the error, I already tried uninstalling IVF, repairing the Visual Studio and reinstalling IVF. But that didn't solve the problem.

Any ideas about what is it that I'm doing wrong? (the VS-Solution is attached).


John.

[Steven_L_Intel1]

This looks like a compiler bug - I can reproduce it. The first assignment to TEXT is getting an access violation. Please report this to Intel Premier Support.

[jimdempseyatthecove]

What happens if you place a subroutine following a CONTAINS in the dll_mod, just a dummy NO-OP subroutine and call that at the beginning of the main program. Then perform the text=' whatever'. i.e. the call of the subroutine performs the load (binding) of the dll to the virtual memory of the program. This may make the pointers to the text valid.

Jim Dempsey

[John4]

Well, this compiler bug in particular doesn't help me at all --Jim Dempsey's trick seems to work, but not as a suitable workaround (i.e., my actual dll-exe application contains a lot of similar cases).

Thanks for the help anyway.


John.

[Steven_L_Intel1]

John,

Did you report this to Intel Premier Support? If so, please give me the issue number. If you have not done so, please do that and specify the appropriate priority for the issue. Thanks.

[jimdempseyatthecove]

John,

Consider this:

The loading of a DLL is performed by way of a name for the DLL entry point(s). The whereabouts of this DLL is determined at run time at the first call. A system may have many DLLs that contain the proper named entrypoint(s), the selection of which is performed in a pecking order. Until this load is performed there is no way of knowing what the debug symbols are nor where the locations will (eventually) reside. (look at articles relating to DLL Hell)

Applications can be written generally in two ways

a) Make the first call into a DLL "Blindly". i.e. let the O/S go through some pecking order to locate something that qualifies as matching the call.
b) Explicitly loadingthe required (and specific)DLL during initialization.

If using b) then likely you also have an INIT call into the DLL which could suffice for the step into to get the debug symbols.

Jim Dempsey

[John4]

Steve: Yes, I reported it, and according to the second issue update, they're investigating. The issue number is 458826.

Jim: I don't see how your last post relates to my issue (i.e., it reads just like "Shared Objects 101"), and in any case I already uninstalled and reinstalled a previous version... But thanks, anyway.

John.

[John4]

Steve:

I just installed IVF 10.1.014... and although I don't get "First-chance exception" anymore, I now get "forrtl: severe (157): Program Exception - access violation". My test program is still the same:

!In the dll:
module dll_mod
character(256) :: text
!DEC$ATTRIBUTES DLLEXPORT :: text
end module


!in the main program:
use dll_mod
text = ' whatever'
text = ADJUSTL(text)
write (*,*) text
read(*,'(A)')
end


Am I missing something?


John.

[g_f_thomas]

The dll source you posted seems to export DLL_MOD_mp_TEXT. Is that what you intended?

Gerry

[John4]

Nevermind... The IDE was still using 10.1.013 (I forgot I had to change it in Tools > Options).

Thanks for the help!!


John.