forrtl: severe (151) or severe (173) errors encountered with DLLs built in IVF 19.2.190

[avinashs]

I have a subroutine (say SUB1) that works without error when built with default calling convention and multithreaded compiler options. However:

1. When SUB1 is built as a DLL with /iface:cvf /libs:static /threads /dbglibs compiler options under the release configuration for planned subsequent use with Excel and other programs, a test main program invoking SUB1 through the DLL encounters the following errors:

    forrtl: severe (173): A pointer passed to DEALLOCATE points to an object that cannot be deallocated
    forrtl: severe (151): allocatable array is already allocated
    
2. When SUB1 is attempted to be built as a DLL under the debug configuration, compilation fails with the message: Compilation Aborted (code 1)

3. This seems to be a recent development since I did not encounter these problems in version 18.

What could be the possible cause?

[Steve_Lionel]

The error messages are rather self explanatory. If not correct, those errors could be caused by data corruption elsewhere in your program. Without a reproducible example, that's as far as I can go.

[jimdempseyatthecove]

WRT 1)

Have you compiled with full diagnostics enabled? This is to catch calling errors within your DLL. This will not detect errors in the code that calls the DLL.

Do you have a subroutine or function declared with an allocatable dummy argument? (and which is called with a non-allocatable argument)

Are you using pointers to an array (and passing an uninitialized pointer to an internal procedure that requires the pointee be allocated)?

WRT 2) compilation should never abort. Can you use conditional compile directives to narrow down the problem?

!DIR$ IF (.FALSE.)
  ... ! excluded code
!DIR$ ENDIF

Jim Dempsey

[avinashs]

Thanks for the responses. The problem is now solved. Based on the above suggestions, I looked at the project settings and there was an issue with the .mod files. It turned out that there were subroutines that accepted an allocatable array or pointer as an argument. However, the debug version was correctly accessing the .mod files but the release versions were either not referencing the .mod files or were referencing the wrong versions. After copying the updated .mod files to the default module directory, the problem disappeared. I had taken care to have different versions of the .lib and .dll files for debug and release versions but the .mod files were being accessed from the debug version even for the release build.