Memory Leak with COM Server

[brownts]

Using COM Wizard, I have developed a Fortran COM server application that is called from Visual Basic. Both the Fortran and VB applications work fine, except that there is a memory leak. Everytime a particular method is called, the memory usage increases ~8K. If the calls to the method are removed from the VB application, there is no memory leak. If all of the function of the method is removed from the Fortran, leaving just a dummy method, the memory leak does still occur. This leads to the conclusion that the problem is in the code generated by the COM Wizard, which leaves me at a bit of a loss as to how to debug.

Has anyone seen this occurring? I am running Version 6.5.A on Windows NT.

Thanks.

[Intel_C_Intel]

Hi,

I'm not aware of any leaks. If you'd like to send the COM server and VB client to vf-support, I'll take a look at it.

Leo

[brownts]

Leo,

I am in the process of paring the project down to bare bones to get something that I can send you complete. Probably send it to Compaq tomorrow.

Trent

[Intel_C_Intel]

Hi,

Ive made the same discovery but the other way around. Ive made a COM -dll written in VB and I used the wizard to access it from VF. Everything works fine but there is a memoryleak when using strings and variants. No solution found yet
Im using Windows NT/2000 and VF6.1a

/Martin

[Intel_C_Intel]

The COM Server Wizard is a different beast than the COM Module Wizard.

Prior to CVF 6.5 the Module Wizard generated code for intent(in) BSTRs that had a memory leak. This was fixed in 6.5. If you don't want to upgrade, then the solution is to call SysFreeString on the local integer (BSTR) variable in the wrapper function $ISomeInterface_MethodFoo after the actual COM method call is made.

Do you have an example of a memory leak with Module Wizard generated code using variants? I'm sure people would be interested in seeing it.

hth,
John

[brownts]

Martin,

My first note seems to have misdiagnosed the problem. We have been trying, off and on, to isolate the problem down to a concise piece of code. We also are using Fortran to access VB COM objects including passing strings and variants. The memory leak appears to occur when we convert a fortran character strings into a variant and send this to VB. Sounds similar to your problem. When we get it completely isolated we will send the code to Compaq.

Trent

[Intel_C_Intel]

Trent,

The wrapper code that the Module Wizard generates for variants pretty much just passes what the caller has provided to the COM object's method (sometimes it makes a shallow copy like in the case of an optional arg). I'm having a hard time imagining where it could create a leak. Makes me wonder if the code that calls the wrapper is properly dealing with memory wrt variants and BSTRs.

COM memory management requires that If the argument is intent in, then the caller is required to allocate and deallocate the memory. If the argument is intent out, the method will allocate and the caller gets to deallocate. There's a brief example below if it helps at all.

Just a stab in the dark,
John

 
 
    ! COM memory management 
    ! For intent in args, the caller owns the memory.  In this case,  
    ! caller allocates and deallocates memory for the string 
    function foo_intent_in(pObj, Str) result  
        use dfcom 
        implicit none 
        ! dummy vars 
        integer, intent(in) :: pObj 
        character(len=*), intent(in) :: Str 
        integer :: r 
 
        ! locals 
        integer :: bstrStr, hr 
        type (VARIANT) :: vStr 
 
        ! body 
        ! convert to BSTR for packaging in a variant 
        bstrStr = ConvertStringToBSTR( Str(1:len_trim(Str)) ) 
 
        CALL VariantInit(vStr) 
        vStr%VT = VT_BSTR 
        vStr%VU%PTR_VAL = bstrStr 
 
        hr = $ISomeInterface_MethodFoo_IntentIn(pObj, vStr) 
 
        r = hr 
        hr = VariantClear(vStr)     ! calls SysFreeString  <===  critical 
    end function foo_intent_in 
 
    ! For intent out args, the COM method allocates memory for the string  
    ! and the caller deallocates it. 
    function foo_intent_out(pObj, Str) result  
        use dfcom 
        implicit none 
        ! dummy vars 
        integer, intent(in) :: pObj 
        character(len=*), intent(out) :
: Str 
        integer :: r 
 
        ! locals 
        integer :: bstrStr, hr 
        type (VARIANT) :: vStr 
 
        ! body 
        CALL VariantInit(vStr)      ! must pass an initialized variant 
        Str = " " 
 

[Intel_C_Intel]

Gotta love that forum message size limit. <>
Get the sample at http://www.termine.org/f90/variantmem.f90

-John