Releasing a Fortran Com server from memory

[Jonathan_Mills]

Hi,
I've posted something similar a lng while back but am still really struggling with this so any help woud be much appreciated. I have a large fortran DLL that was created using the com server wizard. The program runs OK when it is called from vb.net. However when I repeatedly call the dll from vb it keeps tying up memory until it crashes after several calls. In between each call from vb I set the dll object = nothing. The object also goes out of scope in vb and so I assumed should be destroyed anyway. However, if I debug the code I find that subsequent calls to the fortran are essentially using the same fortran object. The variables in the fortran are holding values from the previous call etc.... (and the memory leak continues).

I understand that the destructor routine created by the com server wizardis called and I have checked that this code is actually reached at runtime (it is). What sould be in this destructor routine (assuming this is the cause of my problems)? I have many many variables in the various modules of the fortran program. Can I just kill everything off with a few lines of code?

Am I making any sense?!
Jonathan.

Code showing destructor routine is below:

!Release Function is below:
!****************************************

function SiliconCow3_Release (pData) result
!dec$ attributes stdcall :: SiliconCow3_Release
use ifwinty
use SiliconCow3_global
implicit none

type (ISiliconCow3_Ptr) pData
!dec$ attributes reference :: pData
integer r

type (SiliconCow3_Data), pointer :: pSiliconCow3Data
integer status

pData % pInternalData % refCount = &
pData % pInternalData % refCount - 1
r = pData % pInternalData % refCount
if (pData % pInternalData % refCount == 0) then
! Time to delete ourself....
pSiliconCow3Data => pData % pInternalData % pStart
! Call the "destructor"
call SiliconCow3_DESTRUCTOR(pSiliconCow3Data % InternalData % pInstanceData)
! Per interface
deallocate (pSiliconCow3Data % ISiliconCow3_InternalData % pVtbl)
deallocate (pSiliconCow3Data % InternalData % pInstanceData)
deallocate (pSiliconCow3Data)
status = ServerUnlock()
end if

end function


!Destructor routine is below:
!*******************************************************

! USiliconCow3TY.f90 - This module contains user-defined class
! definitions and methods
!

module SiliconCow3_USE

type SiliconCow3_InstanceData
sequence
! DO NOT REMOVE THIS LINE
! TODO: Add fields and remove "dummy"
integer dummy
! DO NOT REMOVE THIS LINE
end type

contains

!
! Constructor
!
function SiliconCow3_CONSTRUCTOR( ObjectData ) result (hresult)
use ifwinty
implicit none
type(SiliconCow3_InstanceData) ObjectData
!dec$ attributes reference :: ObjectData
integer(LONG) hresult

hresult = S_OK
! DO NOT REMOVE THIS LINE
! TODO: Add field initialization code
! DO NOT REMOVE THIS LINE
end function

!
! Destructor
!
subroutine SiliconCow3_DESTRUCTOR( ObjectData )
implicit none
type(SiliconCow3_InstanceData) ObjectData
!dec$ attributes reference :: ObjectData
! DO NOT REMOVE THIS LINE
! TODO: Add field cleanup code
! DO NOT REMOVE THIS LINE
end subroutine

end module

[Steven_L_Intel1]

I don't claim to be an expert in this, but your COM server I think runs as a DLL and once loaded, it stays in memory until unloaded. Can't you just reinitialize the context? I think nulling the handle just prevents reclaiming the storage.

[Jonathan_Mills]

Quoting - Steve Lionel (Intel)

I don't claim to be an expert in this, but your COM server I think runs as a DLL and once loaded, it stays in memory until unloaded. Can't you just reinitialize the context? I think nulling the handle just prevents reclaiming the storage.

Thanks for the help Steve, and sorry for the slow reply but I didn't realise anyone had responded. Yes it is a DLL but not being a programmer by formal training I don't really know what you mean by "reinitialize the context". Could you give me a quick code example perhaps?!

Any help would be hugely appreciated.
thanks,
jonathan.

[Steven_L_Intel1 · Accepted solution]

What I mean is not depending on static initialization, but having a routine you call to establish the initial state so you're not dependent on what's left over.